iOS

Accepting money on the iOS App Store - acquiring an EIN

Oliver Brown

To sell an app (or an in-app purchase) on the iOS App Store as a non-US citizen, a tax ID is required* to fill in a W8 form. That is either an ITIN (Individual Taxpayer Identification Number) or EIN (Employer Identification number).

As an individual, the ITIN would appear the most correct option. The last time I investigated it, it was a slow process that would require notarised copies of supporting documentation.

Getting an EIN is much easier, and despite the name, does not require you to have employees. All you need to do is be in business (which selling in the app store is) and being a sole proprietor (sole trader in the UK) counts.

In theory, you fill in form SS-4 to get one. It’s very straightforward, and even has an explanation of exactly which parts you need to fill in (look for notes for “IF the applicant… Is a foreign person needing an EIN to comply with IRS withholding regulations”.

In practice, it is even easier than that. You can apply for one over the phone. They will basically ask you the same questions as on the form, and then give you the EIN there and then. I called “first thing in the morning” (6am for them, 11am for me) and got an answer immediately (they warn you that you could be waiting an hour during busier times). The whole process took less than 10 minutes. The hardest part was confirming how my address should be written down. The net result of all this is that Tic-tac-toe Collection’s single in-app purchase has been enabled (at least for beta testers).

* Whether it is actually required is unclear. The old Xbox 360 program, Xbox Live Indie Games, allowed developers to sell without a tax ID, but a 30% withholding tax would be deducted from your earnings. I believe the best result would be the same happening here. It’s also possible Apple would just not allow you to process sales at all.

ListView improvements in Xamarin Forms

Oliver Brown

Since becoming open source, it has become possible to find out potential upcoming features in Xamarin Forms by just poking around the active branches in the repository (macOS support was visible in the repo before any announcement). One of them is lv2spike. From just reading the commit messages, it seems this is a new CollectionView, based on UICollectionView for iOS and RecyclerView for Android. This is something that has been needed for a while, but is a big enough undertaking that I understand why it has taken a while. After all the branch suggests this is still just a spike. There are quite a lot of feature requests for the Xamarin Forms ListView that are just not possible (like this one for horizontal layout) mainly because the iOS implementation is based on UITableView. This will open lots of possibilities. My biggest concern is that despite the push forward with features, Xamarin Forms is accruing bugs even faster, and with the expanded platform support this could just get worse…

This is an imported post and may not be formatted correctly. View the original here.

[SOLVED] System.ExecutionEngineException: Attempting to JIT compile method

Oliver Brown

TLDR: Check multiple references to the same nuget package are all on the same version if you use the Mono linker.

Since my ability to post regularly on things I’m interested in is not great, I figured I could at least post stuff that might be useful. I recently upgraded a Xamarin iOS app from the “classic” (32bit only) API to the Unified API. After doing so I got the error message:

System.ExecutionEngineException: Attempting to JIT compile method
```.

This is caused by the Xamarin (Mono) linker removing code that is only referenced dynamically. The usual solution is to let the compiler know somehow that you are using the code (using a Preserve attribute if it's your own code or something like MvvmCross's [LinkerPleaseInclude.cs](https://github.com/MvvmCross/MvvmCross/blob/f72a92e8a81b9179d1f75d6214eee8c9ca176221/nuspec/TouchContent/LinkerPleaseInclude.cs.pp) otherwisr). In my case, this did not fix the problem. It turns out the Unified API upgrade was a red herring. I had also updated a few nuget packages at the same time. One of them was used in several projects, but I'd missed updating one of them (so I had Project A using v1 of a package and Project B using v2 of a package). This meant my efforts to stop the linker from removing some stuff only worked on one version of the package.
This is an imported post and may not be formatted correctly. View the original here.