I've been saying for years that we need a new App Store. With the Epic/Apple battle being played out in public, I figured I'd describe my current vision for a new App Store model that better serves users today. The obvious answer is just to move iOS to a macOS like system but it's just as obvious Apple isn't willing to do that. My proposal is a compromise that I believe offers a fair direction forward for all parties involved.

First, let me describe the assumptions I'm working with. I'm sure I'll miss something, hopefully nothing that would drastically affect my proposal though. Of course, message me if you think I need to include something I haven't and I'll add updates.

Some Assumptions/Assertions:

1. It's impossible to create an environment that is both useful and 100% safe. Just being alive puts you in danger. This is normal. The goal isn't to be 100% safe, it's to find the point at which users are reasonably safe while still being functional. Anyone that tells you the current situation is 100% safe is lying to you. Arguably, it's also a disservice to tell people they have no risk, or even create a situation where there is no risk.

   Example 1: Even though viruses/malware are rare on macOS, computer experts should never say "get a Mac, they don't get viruses," since then users would think they're safe to just download anything anyone tells them to.

   Example 2: Outside of tech, take the case of playgrounds. In "the old days," as a kid, you could go to the playground and slice your hand on a rusty part, or fall 20 feet from a climbing cage. New regulations made playgrounds ultra safe, all plastic bits, no sharp edges, nothing high enough that you could fall and break a bone. Not only does this create a false sense of security since you can still fall and break something from ground level, it also takes away the opportunity for kids to learn how to evaluate risk.

   Since things can never be 100% safe, it's important for people to also consider the possible outcomes of doing something. Ensure they consider what can happen if they grant an app access to their photos. Think about why a dialog is asking for their password. Teach them to manually save documents as they're working, even with auto-save, sometimes things go wrong. Teach them to make backups on a regular basis, "just in case". Funny story: I wrote the first draft of this post on my iPad in a beta version of an app. When I came to proofread the next day, the beta had expired and the app was no longer in TestFlight. I'd been copying it into Notes every hour or so "just in case" and well, case happened.

2. The App Store itself does not add to the security of iOS devices. Security is provided by various technical means such as user permissions, sandboxing, certificates, kill switches, etc. Some would include App Review in there, but that system is fallible, as we've learned.

3. Different things require different levels of security. For example, personal information such as your name and government identifying numbers require the highest level of security. Photos, contents of emails, contacts etc. require a high level of security, but not quite as high. Payment details (credit card numbers) would be next in line requiring a medium level of security. The reasoning for this is that if someone compromises your government ID, they could cause all kinds of irreparable damage, but if someone gets your credit card number, it's mostly just an inconvenience since fraud happens so often the credit card companies have systems in place to reverse the damage. After all you're giving your credit card number to pretty much every company you buy stuff from online. Not to mention your physical card broadcasting the info to anyone with an RFID reader in their pocket.

4. Apple isn't the only company you can trust with your credit card number.

5. Everyone involved in the app ecosystem wants a fair system. Companies or individuals that want to leech off the work of others without contributing something back are not worth the time to consider.

6. No company should be able to dictate if another company can sell their product/service. That's a job for governments.

7. Apple is not a government.

8. Apple builds iOS and the API used by developers for themselves. This isn't something they've built as a service to developers and for which they need to be compensated. They built iOS and its API's before they ever considered an App Store and allowing third party developers to build apps for the platform. The concept of the App Store was originally implemented by jailbreak users in the iPhoneOS 1.0 days called Installer.app (Wikipedia).

9. Apple means well, but might be too over-protective for their own good.

My Personal Notes

Second, let me state that my personal opinion is that Apple's fee of 30% is not a problem in itself. The problem with the 30% fee is forcing it on developers and not allowing them a choice of service provider. Apple seems to truly believe they're offering value for that money, so opening things up gives them an opportunity to prove it.

More than that, my biggest complaint with Apple is the power they have to decide if another company should be allowed to provide their product/service. They are able to block any app that competes with them (now or in the future), is innovative in any way Apple hadn't considered, or that goes against their values. Apple shouldn't be allowed to project their values onto their customers. If their customers want porn apps, so long as they're legal, they should be able to buy and install them. If customers want to run an app that devours their battery, they should be allowed to do so. It's important to realize that Apple saying "Company X can't sell Y" is the same as saying "Customer Z can't buy Y even if they understand the implications".

The Proposal

With all those points out of the way, here's my proposal for a new App Store model that aims to solve most of these problems.

Apple keeps App Review in place with some changes. Apps are graded into quality tiers:

1. rejected: illegal — this one will need to handle various jurisdictions
2. rejected: malware — attempts to circumvent device security etc
3. accepted: excluded from App Store — low quality/goes against Apple's values/competes with Apple/whatever else
4. accepted: allowed in App Store — high enough quality to be promoted in the App Store

The key difference being that Apple accepts anything that isn't illegal or a valid security issue, but not every accepted app gets listed in the App Store. An app that has been accepted, but excluded from the store can be installed by a user that has a direct link provided by Apple upon approval. Side note: this gives Apple a great opportunity to optimize the App Store since they can remove the millions of junk/neglected apps and only present the best apps to users.

Next, Apple allows alternate store fronts, I'll call these Store Front(s) as a generic term to differentiate from Apple's App Store. These are apps that act as alternate stores users can use to find and install apps. They can include search, categories, editorials, or none of these, it's up to that store runner and how they think they can best serve their users. Store Fronts can list apps that are included, or excluded from the App Store. When a user installs an app from a Store Front, it uses Apple's API to install the app from Apple's servers.

Note, so far, all of this is possible with today's tech already in iOS. Store Front would be just like TestFlight, installing apps securely from outside of the App Store.

Handling payments in Store Front would be something new. While I assert above that Apple isn't the only company it's safe to give your credit card info to, let's stick to exclusively using Apple's payment system in this first step forward. When a user installs a paid app, it still triggers Apple's payment system, same as now, and calls back into the Store Front app with a success or fail response if the purchase (and install) was successful. When the app is installed (paid or free) from a Store Front, the receipt records which Store Front was used in order to handle commissions for the initial sale, plus any future IAPs.

So how is the money split in this new system?

• 3% Payment Provider (always Apple in this first phase)
• 7% Apple (covers platform/review/distribution costs)
• 0-20% App Store or Store Front

The 0-20% for the Store Front is variable and is set in a new section of App Store Connect. App owners will have to authorize whether a specific Store Front is authorized to sell their app(s) and for what % range. A Store Front can use the commission % to compete with other Store Fronts. A range can be set for each store to allow for deals like a featured listing earning the store 10% while a standard listing nets 5% or something similar. Apple should also implement a range and earn a higher percentage for featured listings over a search result. Of course, an app owner can also elect not to have their app listed in the App Store if they choose.

Regardless of which Store Front makes the sale, Apple will process the payment and will split the proceeds from the sale according to the agreed %'s. Apple pays out commissions to the Store Fronts similarly to how they currently pay developers.

So what does all this accomplish?

It solves what I feel is the biggest anti-trust issue with Apple where they can prevent new innovative ideas from being explored.

It maintains all current security measures including user permissions, sandboxing, certificates, and a kill switch (including the problems associated with that).

It enables Apple to continue to earn 30% of sales they facilitate through the App Store.

Customers can still make purchases easily with a single Apple ID.

It allows third parties to create new innovative/curated Store Fronts and earn a commission for sales they facilitate, while still paying Apple a fair cut.

It allows developers to self-promote their apps and save on their commission costs, dropping it from 30% to 10% when their marketing creates the sale. This in turn can revitalize the decimated App Review sites since developers might actually be able to afford to buy online ads and sponsorships again.

What doesn't it do?

It doesn't solve the issue of free apps being able to use all the same development and distribution tools that Apple provides without contributing to those costs. For that, I'd like to see a per user, or per download (perhaps based on file size) cost that is paid by the developer of the free app. If it's $0.25/user for example, that should be a bearable cost (part of the marketing budget) for that company. But this needs to be explored in a whole other post.

It doesn't solve the issue of allowing alternate payment systems. As I stated earlier, this is a first stage. By separating out the payment provider and Apple platform commission %'s, I've opened the door to allow other payment systems later. The hard part is going to be managing the split of the proceeds if a different payment system is used. I also believe that if the payment % is dropped to 3% as I've done here, there's less of a reason to want to use an alternate payment system anyway. Except for the next point...

It doesn't solve the issue of developers not knowing who their customers are. Which an alternate payment system could help with. But if a developer really wants to know who their customer is, they can just ask in the app via an account system. If the user consents, they can supply their info. That feels like a fair way to handle it. Forcing a user to disclose their real identity just isn't cool in today's world.

Bonus notes:

1. One implementation detail to note: when a user buys an app from a Store Front, it would still show up in their normal 'Purchase History' where they can reinstall just as they can do now. It would list the name of the original Store Front, but they wouldn't need to go back into that app to reinstall since it would be possible that Store Front has closed.

2. I've written this with Apple in mind, but I believe the same system can and should be implemented by others in the industry, including the game console makers.

3. While Apple's % take will drop in some cases by implementing this system, I believe they'll actually make more money in the long term. Their devices will become even more powerful as new innovative apps are released for them. Fewer developers will be pushed toward making web and/or Android apps, or pushing customers to make their purchases outside of their apps.

4. I wonder if Apple feels, even if they want to reduce their fees, they have to fight this battle in court and be forced to make any changes in order to avoid being sued for breach of fiduciary responsibility to their shareholders? IANAL!

5. Everyone always cites the 30% number. But it's actually higher than that in a lot of cases. On top of the 30%, developers need to pay $100 USD annually for their developer account. They must buy Mac hardware because Apple's rules state all apps must be built on Apple branded hardware. But the biggest hit here are Search Ads. Developers often have to bid on their own app name and pay Apple extra $ just so their app comes up first in the search results when someone specifically searches for it. When Search Ads were first launched, I tried them out and all it did was drive my 30% fee up to 90+%.

6. I can't wait to see some of the really cool innovative apps that will come out. Even simple things like a third party phone dialer could lead to new ways of doing old things.

Addendums:

1. 2020/08/25 11:30am: Dave Murdock suggests Store Fronts would need to go through App Review as well. And yes, agreed, they're apps and so each update would be reviewed just like other apps. Further, I envision that in order to submit a Store Front, you'd need to be approved with a new type of developer account with it's own agreements, and most likely an additional fee, similar to Enterprise Developer Accounts.

Everyone seems to have their own list of things they want to see at WWDC, so I figured I should throw mine down on virtual paper too. I'll keep it short for you and mostly just include things that aren't on everyone else's lists.

AppStores:

• they all get the 2017 update, adding curation etc.
• (macOS only) allows more powerful (read non-sandboxed) apps back in the store.
• commission rate change: 5% for apps sold via a deep link, 15% for apps sold via search/browse, 30% for apps sold via curation stories/app lists/features.
• ability for devs to merge SKUs, i.e., combine X and X Lite into one app. Any user that had downloaded either now gets the merged version and the receipt lets the dev know which one(s) the user originally downloaded.
• ability for users to browse all stores on any device, make a purchase, and have the app installed on a different device. I should be able to browse the tvOS AppStore on my Mac, buy a tvOS app and have it install on the family room Apple TV.
• new badges on every app that indicate features/warnings, such as: age rating, whether or not the app is sandboxed, has passed an accessibility audit, if there's a complimentary macOS/iOS/watchOS/tvOS app, is on your wish list (which they need to bring back), etc. (Hat tip for the accessibility audit idea from Marco Arment on Under the Radar)

iOS:

• ability to set default apps for email, web, calendar etc.
• add app shortcuts to Control Center.
• better control of audio, routing and setting different volumes (ring vs media etc).
• landscape support for Face ID.
• multiple faces for Face ID.
• bring the iPad keyboard to iPhone (the swipe down on a key for the alternate version feature).
• more granular selection of contacts to allow calls from when in Do Not Disturb mode.
• multi-user support (for iPhone and iPad).

macOS:

• the ability to lock the dock to one screen. Having it randomly fly around all my other screens has driven me nuts for years, especially when I go to click an icon on the dock and then the dock runs to a different screen so I can't click it.
• HomeKit support

tvOS:

• a built-in web browser.
• enable UIWebView/WKWebView in tvOS apps.
• multi-user support.

watchOS:

• complications that can update more frequently (1 minute intervals). Even if this requires user permission to update that often.
• custom watch faces.
• always on display.

Xcode:

• plug-in system, at least restoring functionality that was lost in Xcode 8. I'd even be happy with just a way to restore colour to the console logs.

HomeKit:

• when using automation to turn on a light, be able to turn it off after x number of hours without a second automation. Right now this feature exists, but is limited to 60 minutes. I have several lights that I turn on at sunset, and off at sunrise. They all require 2 automation tasks. Being able to say turn off in 8 hours, would simplify things.

Mac Mini:

• updated Mac Mini's. Maybe even a Mac Mini Pro with Coffee Lake CPUs, Dual 10 GigE ports, USB-A and C/Thunderbolt 3 ports. Up to 128 GB RAM, 4 TB SSDs. Able to drive 3 5K displays.

MacBook Pro:

• updated, with a fixed keyboard design. Coffee Lake CPUs, Up to 64 GB RAM, 4 TB SSDs.
• option to include the Touch Bar and the standard function keys. I feel most of the hate with the Touch Bar was not with the bar itself, but the removal of the function keys (especially the escape key). I’d buy a MBP that included both.

iPad Pro:

• Face ID.

I really wish I could be in San Jose for WWDC this year. It's been a while since I’ve been out with my fellow developers, so you’ll have to have a beer for me. Stay safe, have fun, and hopefully I'll see you next year!

If you've found this article interesting, please subscribe to the RSS feed and follow me on Twitter and/or Micro.blog

It would be awesome if you'd download our newest app All the Rings. It's free and we really think you'll like it!

If you see any errors, want to suggest an improvement, or have any other comments, please let me know.

All indications point to the imminent release of iOS 4.3, if not this week, then certainly by next week. As always with new releases, a host of new features will be included, not just for users, but also for developers.

The rumour is that 4.3 will introduce subscription pricing options to the app store. This is in response to newspaper and magazine publishers looking for better pricing options for daily, weekly and/or monthly editions. But, who says subscriptions need to be limited to publications. Apple's Terms of Services don't. More on that in a bit.

One of the challenges of iOS development is earning enough revenue to make a living. It's been said that there are two app stores, App Store A, where you sell apps with mass market appeal, hoping to generate a lot of revenue in a very short time, and App Store B where you sell apps that target a narrower audience, aiming to generate a steady revenue stream for years.

App Store A is often compared to buying a lottery ticket, and has just recently made an appearance in Dilbert.

App Store B is considered to be the more attainable, long term success strategy. Since you're aiming at a narrower target market, it helps to be able to generate recurring revenue from your users.

I've long wanted to try charging a monthly or yearly fee to use an app, something that will support the development process after the initial sale. Every other software platform allows you to charge for upgrades in order to generate some recurring revenue from your installed user base. A few apps on the App Store have phased out the original version and released a new version, with a new charge. There a few problems with this approach, a) users who buy the app just before the switch, kind of get screwed, b) there's no easy way for a user to transfer their data from version 1 to version 2 (it can be done, but you have to build in a solution, unlike normal app upgrades), c) not all users of version 1 will even know version 2 is available.

Another option is to add new features and charge for them though in-app purchases, then a user can decide if the new features are worth the extra money to them, if not, no harm, they keep using the app as they bought it.

Back to the new subscription option. With subscription pricing there will be a new opportunity to generate recurring revenue from your user base. And to the user, it will be a well defined, easily understood method. $x per time period. Just like paying your monthly phone bill, or a yearly magazine subscription. You can cancel at any time, or keep paying and take advantage of all new features as they're released. For developers, you now have recurring revenue. Earnings to enable you to continue to maintain and support the app, while still feeding your kids.

There's no indication yet what the options will be from Apple, but it's a good guess that the same pricing tiers we're using now will apply, and that you'll be able to select from a variety of time periods, likely: weekly, bi-weekly, monthly, quarterly, yearly. As an example, you'll be able to charge $0.99 a quarter, instead of a one time fee of $2.99. If the user doesn't like your app, they save money. If they like the app, and continue to use it, you'll break even after 3 quarters, and earn more for the entire length of time the user uses your app.

The largest obstacle I foresee moving to this model will be the blow back from customers. The current app ecosystem has bred a sense of entitlement where users (not all, but a lot), feel they deserve an app, all future updates, full support etc, all for the low cost of $0.99. For most developers, and most apps, this isn't sustainable. Using a subscription will help solve this. As more of us developers begin to use this model, customers will begin to accept it and most likely actually prefer it, since they'll know exactly what they're getting and for how much, and their apps will constantly improve at no additional cost. And, all things considered, they'll still be getting their apps at a ridiculously low price.

Update: Apple officially released the information on subscriptions today. Subscription term lengths are: weekly, monthly, bi-monthly, quarterly, bi-yearly or yearly. Thanks Apple for giving developers more opportunity to become profitable!

iOS 4.3 is currently available as a beta and thus is under an NDA. Nothing I discuss here is covered under the NDA to my knowledge as there's been no official word about subscriptions other than the now public iTunes Terms and Conditions. If you feel I have disclosed something in the NDA, please let me know and I'll edit the post accordingly.

Everybody else seems to have a blog, so I suppose Cerebral Gardens ought to have one too. This will be written by me, Dave Wood, the founder and developer.

The issue that has compelled me to finally write something is the whole Tweetie upgrade pricing issue. First, I want to say that I always try to look at an issue from every side, though I'm not always successful at that. In this case it's pretty easy, since I'm both a developer and a user. Next, I'll admit that while I did buy Tweetie v1 for iPhone, I barely use it. I use Tweetdeck most of the time because of it's quick account changes. And Twitterific the rest of the time. Bought Tweetie just because it worked during the twitpocalypse. I do use Tweetie on my Mac exclusively (with the ads 'cause I like the ads, very relevant to me).

So, the issue with Tweetie v2 being a fully new version with no upgrade path is a tough one. Largely because developer’s choices are limited due to some of the restrictions imposed by the App Store. Enough people are writing about how to fix the store, so I'm going to present options that may work with the current setup of the store.

There are two main problems to deal with here (again, not counting the App Store issues). 1. Users expectations for free updates. 2. Developers needs for a sustainable business.

Regarding users expectations for free upgrades: I believe there should be an expectation for free upgrades for some length of time whenever someone buys software. That time is up for discussion. With a $1500+ Adobe Suite purchase or even Apples $69 iWork product, I believe that time period should be at least a year. With a $3 app, perhaps it should only be 30 days. Although I believe current users are expecting longer. Anyone expecting, or offering, lifetime updates is insane. That's obviously not sustainable.

But the expectations do exist; whether or not they should. Developers (myself included) need to start setting customer expectations to match our plans. Stating what the upgrade path will be in our app description for instance. Just stating something like 'free upgrades for 30 days' etc. As I type that I have to laugh. With a 14-20 day review process 30 days doesn’t seem like enough. 3 months perhaps.

John Gruber of Daring Fireball fame (whom I read religiously) compared buying a $3 app to a $3 cup of coffee. I don’t believe this is a fair comparison. The only thing they have in common is their price. A cup of coffee is a physical item, actual water, coffee beans, cream and sugar maybe, as well as a paper cup, and a plastic top. A person has to physically take your order, prepare the coffee to your taste, and hand it to you. The whole process takes a minute or so of someone’s day. If 1000 coffee’s are ordered at the same time, it takes a lot of people to serve them up in the time expected by the customer. Compare this to apps. There’s nothing physical with an app, not even a disc with iPhone apps. Once the app is made (and of course there is a cost there), it doesn’t cost much more per app ordered. It costs the developer (almost) the same to develop the app whether it ends up selling 10 copies, or 10 million copies. A closer comparison would be comparing apps to songs. We pay about $1.29 per song now. Imagine the uproar if songs were $3 each. Heck, I think $1.29 is expensive, but I pay it.

Continuing to compare to music, consumer’s expectations have been set; people buy a song or CD and they’re done. They don’t expect to get the same song again in a new format if it comes out; people joke about how many times they’ve bought the White album. They don’t expect to get an extended, or remixed version of the song for free if one comes out. The point here is that expectations of users can be set to be very low.

Perhaps this is what Atebits is starting to do. They’re reducing the expectations of their users, drastically. Possibly too fast, hence the uproar.

I've read that Atebits has said they would like to offer an upgrade path that gives current users a discount, but that it's not an option with the App Store. Here's one way it can be done. (This isn't pretty and I wouldn't recommend anyone else do this; further below is an option that could work for the rest of us, with time to plan).

Set Tweetie v1 to $999. No sane person would buy it at that price. If they do, Apple will refund it, (and hopefully not ding you the full refund price as indicated in the dev contracts). Then submit v2 as two apps, an update for v1 users, and a new app for $3 with text in the description to set the users expectations correctly. V1 users get the update they expected and also have their expectations for future updates set to nil. When v3 is ready, v1 and v2 are removed from sa le, v3 is submitted as a new app.

Regarding problem 2, the sustainable business: obviously developers have to be paid for their work, and continue to be paid for building upon that work. I’m going to assume that the incredibly low app prices aren’t going away; even if most developers raise their prices, there will always be bottom feeding app spammers (such as Brighthouse Labs) selling crap for $0.99.  So Atebit’s plan to release Tweetie v2 as a separate app actually makes sense (after setting expectations correctly).  But lets take it a step further.

I believe that we should be selling our software based on the time the user will use the app. Pick a value you want to charge per month of use, in this case, we’ll go with $1/month. Adjust these rates when/if prices in the App Store in general change. If you estimate your app has a 1 month life for the user, perhaps a game that will become boring/be completed in that time period, charge $1. If it's good for 3 months, charge $3. If the app is like Tweetie and useful for a year, charge $12. From here, we get my other possible solution (for the rest of us).

This option requires planning, so it's too late for Tweetie. If you expect a 6 month life of the app from v1 release to v2 release, price the app at $6. Each month drop the price of the app by $1. When v2 comes out, price it at $6 again. V1 goes to free, but is unsupported, or could even seize to function if that’s made clear to the user before they buy it. This is giving your users a set cost per month of usage. It’s not perfect, but much closer to what people expect, and it's a sustainable business model for us developers. I believe this will work extremely well if lots of us start using the model. This could likely be implemented via in app purchasing, by charging for each month of usage.

I’m going to stop here, without a final conclusion since I consider this just part of an ongoing discussion. I look forward to continuing to discuss these issues further and working with others in the community to solve these problems (among others) while creating successful businesses.