Title: Why I Don’t Develop for iOS

Author: Bob Schmidt

Date: 08 January 2020 19:28:16 +00:00 or Wed, 08 January 2020 19:28:16 +00:00

Summary: Silas S. Brown tells a cautionary tale of the App Store business model.

Body: 

When I wrote a utility to help a local cancer-research team organise an experiment they were doing, it occurred to me that other medical research labs might also benefit from the utility, so I contacted someone I know who worked at another lab to see if they were interested, but she said her lab does not risk running software unless it’s been published in a peer-reviewed bioinformatics journal. Fair enough, I thought, so logically I set about getting a peer-reviewed publication about my utility. This has been published by Oxford University Press and I understand some labs are now starting to use it.

Now, academic journals come in two types: traditional closed-access, where the reader (or the reader’s institution) pays to see the article, and modern open-access, where there is no charge to the reader but the author (or the author’s institution) pays a publication charge. We opted for an open-access journal, but as my current affiliation with the university is merely that of being a teaching assistant in a different department, I realised that trying to get the university to pay my open-access publication fee would take a very long time (if it could be done at all), and I didn’t want the whole world’s cancer research to be waiting for that, so I just paid it out of my own pocket and said ‘that should cover my donations to cancer research for a while’.

When I paid that open-access fee, there were two important things I knew: (1) that the paper had already been accepted in principle and (2) that the publication is permanent.

Paying for consideration

I might not have been so keen to pay the publication fee myself if it had merely been an ‘entrance fee’ that must be paid up-front before they even looked at my submission, with no possibility of refund if I’m rejected. That is what happens on Apple’s App Store, so if you don’t have too much money to burn on the expensive up-front subscription costs, not to mention equipment costs (you need to keep buying the latest Mac hardware to stay current), you had better be highly confident of your chances of passing Apple’s app selection panel before you pay up to find out. My app was based on a browser, and I’d already had it rejected by Amazon (apparently because they don’t want any competition to their own Silk browser on their store), so despite its popularity on Android I wasn’t at all confident enough to risk paying for Apple to consider it.

Now, people do pay examination fees for driving tests. I chose ‘driving tests’ for this example because the result is a strict pass-or-fail (no B-grades etc: let’s not consider ‘Pass Plus’ for now), the financial risk is not made complicated by the existence of scholarships or ‘loans’ that don’t actually need to be repaid in the event of insufficient salary, and the test fee itself covers only the test and not any education that goes with it (well you’re more likely to pass if you invest in some lessons too, but that’s separate). Paying to get your app considered by the App Store could be likened to paying for a driving test: in both cases you might fail, in which case the only thing you gain from your test fee is the rejection letter. But at least with a driving test you can learn what went wrong and take it again. This is not always possible with the App Store. Yes they might point out a small problem that can be corrected for re-submission, but if they reject the very principle of your app, then that would be like failing a driving test on medical grounds. How many people pay for a driving test when they’re likely to fail on medical grounds?

The other issue is the amount that’s charged. If you’re running a competition and you want individuals to enter, you had better not set the entry fee so high that they’re put off from trying. In the case of the App Store, the entry fee is 100 pounds for the developer account plus the cost of any new equipment that’s needed (although this is partially offset by the fact that you still get to keep some decent hardware in the event of failure), and the prize is simply that of being allowed to help users by publishing your app on the Store. (Yes if you have a wildly-popular app and you are willing to ‘monetize’ it then there might be a financial prize, but in most cases this is unlikely and I’d rather focus on ‘helping users’.) I believe they have set this figure incorrectly and I’d rather tell my users to switch to Android.

Perhaps Apple would do better in business if they broke the fee into two parts: a low ‘consideration’ fee and a higher ‘publication’ fee. The first fee pays for the time of somebody to look at your app and say ‘reject’, ‘accept if you pay the full fee’, or perhaps in especially good cases ‘accept without further fee’ (after all Android manage to charge only 25% of Apple’s fee and waive renewal payments, so I expect Apple can afford to take the best apps on their own merits).

Renewals

Hosting an app on the App Store comes with a rather high annual hosting fee. One year alone of this hosting fee is four times what Google Play charges for life (and that’s not even counting the fact that you must keep up with Mac hardware that is supported by current versions of macOS in order to run acceptable versions of Xcode to submit to the Store; with Android you have a much broader choice of developer equipment). This is not as off-putting as the fact that you might pay all this and still be rejected, but it’s still rather unpleasant if all you’re trying to do is help the users.

Developer pooling?

I tried to find existing Apple developers to publish my app. After all, if they’ve already paid up, it shouldn’t cost them extra to piggy-back my app onto their account as well, and I don’t really care whose name appears on it as long as it gets out there. But the reactions I got were generally along the lines of ‘I don’t want to risk my standing with Apple by submitting code I didn’t write’, or ‘if you say you want it to be a free app with no ads, I don’t want to bother because I only want to monetise’, or ‘the latest Xcode says you’re using a deprecated API, so I don’t want to risk trying to submit.’ Are Apple developers not even allowed to make a test release with a deprecated API call? I might want to see if the general idea of the app will be accepted by the Store editors, and to see how many users it gets, before deciding to take the trouble rewriting it to suit the ever-changing whims of Apple’s API designers, especially if that means investing in new developer equipment. What’s wrong with submitting anyway and seeing if we can get a ‘yes in principle’ first?

Is there an ACCU member out there who happens to have a paid-up App Store account and might be willing to compile and submit apps from other ACCU members? Bear in mind this means taking final responsibility for the code: although Apple allows you to use other people’s code in your app (think ‘libraries’) if you have a licence to do so from the original developer, it’s still considered your fault if the library does something obnoxious like renders the end-user’s phone unusable, so if you’re going to run such a service you had better be good at proof-reading source code, and it’s understandable to be trigger-happy on the ‘reject’ button if it looks a bit like ‘underhanded C’, although the mere use of deprecated APIs is not in itself underhanded, it’s just something that would need fixing in the event of the apps being accepted and getting enough users to make further development worthwhile.

Losses

I don’t expect Apple to read this, but in case any other readers are thinking of setting up a hosting business like the App Store, it might be worth considering how much money Apple might be losing from their less-than-ideal treatment of app developers.

Naturally I recommend users choose Android over Apple if they want to use my software. I did once get a sharpish reaction along the lines of ‘you shouldn’t be telling people which phone to choose, it’s YOUR fault if it doesn’t run on Apple, YOU fix it’, but that tends to be the exception. Few people would immediately rush out to change their phone just to use my program (it’s not THAT good), but I have heard it has entered into people’s Android-versus-Apple decisions when they are going to buy a new phone anyway, and I have heard of people not switching from Android to Apple because doing so would lose my app.

I now have about 4,000 active users on Android (having lost about 1,000 over 6 months when a large website started providing a similar-but-not-as-complete service); I don’t know how many of my users have thought of switching to Apple, but in the worst case (from Apple’s perspective) I could be holding them back from over a million dollars worth of phone sales just because Apple wouldn’t let me try their submission process without paying a thousand up-front. Multiply that by a few other nice app developers and you can see Apple might be missing out an serious money because of their decision to kill off the ‘long tail’ (the area under the graph contributed by small less-popular apps that might not amount to much individually but add up to more than you think when they’re all taken together).

I don’t know about running businesses: I’m just a developer; don’t expect me to make good business decisions; for all I know, there might be a good financial reason for Apple to take those losses. But there might not. Either way I feel it should be pointed out.

And if anyone out there is thinking of learning some iOS development, I’m sorry to say my current recommendation is ‘don’t bother’, not unless you are absolutely certain of getting paid for it (as in you have already secured employment at a company that now wants you to learn it); the costs are too high otherwise. This does not bode well for the long-term future of the platform.

Silas S. Brown Silas is a partially-sighted Computer Science post-doc in Cambridge who currently works in part-time assistant tuition and part-time for Oracle. He has been an ACCU member since 1994.

Notes: 

More fields may be available via dynamicdata ..