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.

Big news from Apple today:

Starting on May 1st 2017, commissions for all app and in-app content will be reduced from 7% to 2.5% globally.
Screenshot via @drbarnard on Twitter

Apple is reducing commissions paid to sites who promote our apps by 64%! That's a huge cut and they're only giving everyone involved 7 days notice.

The app economy has been tanking for the last few years. Apple must know this by now, even though they tout how great it is (maybe it is for a few big companies such as Niantic Labs, Nintendo etc). Personally I think this change in commission rate must be part of something larger, aimed to help rejuvenate the ailing app economy.

Back in June, 2016, Apple announced the first change in the percentage developers pay Apple, dropping the 30% rate to 15% but only for those using subscriptions, and only after a customer has been a subscriber for at least a year. For the most part, this would only have helped a few developers so far, since only a limited number of developers were even allowed to use subscriptions until the June changes. Those would be the Netflix/HBO type apps that are worth billions and don't need the extra help.

What I'd like to see at WWDC this year, is for Apple to announce they are finally reducing the 30% rate we pay to something more reasonable. Let's say 15%?

Assuming that's the plan, how about this as a proposed alternative? Instead of dropping the rate to 15% across the board, Apple could drop the rate to 15% for apps installed organically, and 20% for apps installed through an affiliate link. That extra 5% could then be paid to the affiliate who earned the sale. As a developer, I'm fine with that since it only helps those who help me.

I feel this would be a win-win for all involved. Developers get a much needed drop in their commission rate. Promotion sites such as iMore, touchArcade, etc will get a small bump instead of a drastic cut in their earnings, and Apple gets to keep the new 2.5% affiliate commission rate. I know dropping the developer rate isn't ideal for Apple, but it would make a big difference for the people who help keep their devices in demand.

What do you think about this proposal? Please @ me on Twitter and let me know your thoughts.

With the recent announcement of some App Store changes, and WWDC just days away, I figured I’d better write about an idea I had before it’s too late. I’ll keep this much shorter than the version that’s been floating around in my head.

I would suggest that Apple release their grip on the App Store, and start allowing other stores on iOS/tvOS which would, essentially create an App Mall. Open it up so that anyone can create a store. These will be distinct apps developed like any other third party app, clearly branded to avoid user confusion with Apple’s App Store. I envision stores created by brands you already know: TouchArcade, 148Apps, AppShopper, Google, Microsoft, Panic, OmniFocus, RelayFM (for sponsored apps) etc; as well as new ones that will appear.

These stores would be akin to radio stations. If a person likes Rock and Roll, they tune in to a Rock and Roll station. If they prefer Jazz, they listen to a Jazz station. Every once in a while you listen to something different. We’ll have stores that focus on pro apps, stores for games, a store for writers, developers, parents etc. Users will come to know and trust the curators of their favourite stores. This plan delegates some of the curation of apps out to the community where it can be handled much better (just because of sheer numbers). It doesn’t take away from Apple’s App Store curation, rather it enables a method to better group apps and aid with app discovery. Instead of trying to fit 2+ million apps into 25 categories, there will be another layer on top to help sort.

One huge side effect to this plan is that Apple would have more control over it’s own App Store. They will be able to delist a tonne of bad apps, and stop adding new bad apps by raising the criteria that allows apps to be listed in the official App Store. If an app is ugly as sin, riddled with spelling errors, etc, they can refuse to include it in their store, just as Saks Fifth Avenue can refuse to stock substandard products. Right now, Apple has a set of rules, and if your app follows those rules it should be allowed in the store. Ugly apps should never be featured anyway, but they still come up and clutter the search results, they still show up in the “Customers Also Bought” section. With my new plan, those apps won’t show up at all. It’s my belief that Apple has to generally accept any app that follows their rules, or else they’ll start to run afoul of anti-competition laws. Since there is no other way to sell apps to users with iOS/tvOS devices than through the Apple App Store, if they reject apps based on religious beliefs, politics, bad UI, etc, they are preventing other companies from operating, and could get into trouble.

It would sort of be like Panasonic selling a radio, and then saying no Justin Bieber songs can be played on them. How long would it be before Panasonic was dragged into court by the Department of Justice? So my point here is that because Apple would be allowing developers to list their apps in other stores, they’ll be free to be more selective in their own store.

None of this affects app review, signing, pricing or privacy BTW. All apps would still go through review (though it would be more for weeding out malware or buggy software). Apps would still be signed by the developers and installed from Apple’s servers. Just as the TestFlight app can install apps that aren’t in the App Store, third party stores would also be able to use an API to trigger app installs (securely of course, apps wouldn’t be able to install other apps without the user’s explicit permission). The price of an app would be the same, and the payment would still be handled by Apple. So privacy is preserved as Apple would still be the only one to know who the customer is. Apple could still take their 30% (or now 15% in some cases, hopefully more cases soon). The third party store developer would be compensated via the already existing affiliate program. Or depending on the store, they may charge the developer for a listing, just as grocery stores charge food producers for the valuable space on the end of the aisle.

The goal of this idea is to help with app discovery. By opening up the App Store in this way, it empowers the developers in our community to help solve this major problem that’s really hurting the platform, without compromising the security or privacy of the platform that users have come to expect.

WWDC 2012 sold out in less than 2 hours, a record that had been easily predicted by many. Tickets went on sale at about 8:30 Eastern time and were sold out before most people on the west coast had even woken up. The demand for tickets was obviously extremely high, and the supply was limited to about 5000. How can Apple solve this for next year?

Of course, the first question is, does Apple even want to solve this. I believe they do. They have information they want to put into the hands (and heads) of developers, as many developers as possible. That's why they release the videos shortly after the event. That's why they've had the free Tech Talks in various cities. So yes, Apple does want to get the information out to many developers as they can. So it's to their advantage to increase the supply of tickets for WWDC.

One idea that often comes up when this topic is discussed is to have two events. Perhaps keep the first one in San Francisco and have another a couple of weeks later somewhere in Europe. The SF one would have the main Keynote for press, just like the present; the Europe one would skip the keynote but have all of the same sessions. This would temper the expectations of the press, who may be disappointed if the event were held months later without additional product announcements. The SF one would still be called WWDC, but would now actually be 'Western World Developers Conference', the Europe one would be EWDC, 'Eastern World Developers Conference'. The downside of this scenario for Apple is the increased cost, not just the direct costs of hosting an event in Europe, but the time involved in tying up Apple's engineers for an additional week (or two including travel/prep etc).

My personal suggestion is to keep it as one event, but increase attendance to about 10,000. The most common argument against this idea is that Apple likes to have a roughly 1:5 engineer to developer ratio, and they don't have enough engineers available to maintain that ratio if they double the developer attendance. I've only been to one WWDC, so this could be inexperience talking, but to me, the number of engineers there was almost irrelevant. Each session had 1-5 engineers on stage, but it didn't matter whether there were 500, 1000, or 2500 people in the audience, only the size of the room affected how many people could attend. Where the number of engineers matters is in the labs (which are more like Q&A sessions than labs). So I have an idea to increase the usefulness of the labs for everyone, while at the same time increasing the efficiency so that the same number of engineers can support 10,000 attendees.

The idea is to have attendees submit the questions that they intend to ask an engineer in a lab, to a special WWDC lab email address (along with their project source if applicable). These questions will be prescreened by Apple engineers (or even interns) way before WWDC. Some questions will be simple enough that an email response will be enough to answer them. For the rest, an appointment at WWDC can be scheduled with an engineer that can actually answer the question for the developer. In a lot of cases there will be duplicate questions that can be answered in a group session. This plan will reduce the need to have such a high ratio of engineers to developers while increasing the value of engineer and developer meetings. No more lining up to talk to an engineer that doesn't know any more about the problem you're trying to solve than you.

The only other logistic is how to fit an extra 5000 people ino the sessions. My plan there would be to expand to Moscone North and/or South, and make all of the rooms bigger. Same number of sessions, same number of engineers, just a larger audience. I heard developers this year talk about how long the lines were to get into each session, and that they weren't that long in previous years. But the consensus seems to be that Apple was just way better organized this year than in previous years and that the lines just looked longer than a massive mob of unorganized people. My point here is that Apple did a great job of moving the 5000 attendees around this year. If they increase the time between sessions a little, it should be possible to move 10,000 people around the 3 buildings efficiently.

Whatever the plan, I can't wait to attend WWDC 2013.

If you enjoy reading my blog, please follow me on Twitter, and/or like Cerebral Gardens on Facebook.

This was my first WWDC, but it certainly won't be my last. It was a great experience and I'm going to try and share some of the things I learned over the last week. Nothing that's covered by the NDA of course.

1) It was great to finally meet some of the big wigs in the community. Drinking beer with Jeff LaMarche and the other MartianCraft guys. Hanging out with the Empirical Development guys that I've been working with for most of the last year was awesome. Getting to pitch Party Doodles to Eli Hodapp (of Touch Arcade) and Victor Agreda, Jr of (TUAW) in person was amazing. I'm sure it helped that Apple basically used Party Doodles as an example of how to do an AirPlay game correctly.

2) Probably the biggest shock to my system was the amount of walking involved. As someone who normally sits at a desk for 12+ hours a day, it was a major change to walk back and forth from my hotel 2 or 3 times each day. Why 2 or 3 times you ask, depending on whether or not I took my laptop to the sessions and wanted to drop it off at my hotel before dinner/socializing etc, or based on meetings with various people I had scheduled between sessions.

3) In most cases, you do not need to take your laptop with you to the sessions or labs. I had a completely incorrect assumption of what the labs were. Labs should be considered more like Q&A sessions with Apple engineers. They are not planned tutorials or anything scripted. They're just a chance to ask a question, sometimes with someone who may have helped build the system you have a question about. The only time having your laptop with you is probably if you need to show an engineer your code during your Q&A (lab) session.

4) For the labs, my own experience was pretty dismal in this regard. I had a few questions to ask about various topics, and each time, the engineer(s) I was talking to had no more information to provide on the issues. That being said, I heard of some people that had much more successful visits to the labs.

5) The actual sessions where amazing. Some covered brand new information about iOS 6 or Mountain Lion, while others covered older information that you might have missed. Sometimes you see something presented that's been available for a while that you just hadn't seen and you think "this will save me hours". When the session videos are released, make sure you watch as many as you can. Even if you think you already know about a topic. There are always extra little tips that are invaluable.

6) When you attend a session in person, please use some common decency and follow these four rules:

1. When sitting down, move to the center of the row, don't 'end cap' the row by sitting in the first seat. Most sessions fill the entire room and when everyone has to fill in rows by jumping over a person sitting in the first seat, it's pretty annoying.
2. Wait until the speaker has finished talking before running out to the next session. We all have to get to the next session at the same time, give the speaker the respect they deserve by letting them finish.
3. Do not use a MiFi device. They jam the provided WiFi and in some cases prevented even the presenters from being able to demonstrate what they had planned.
4. Take your trash with you. If you bring in a drink, lunch etc, just take the garbage with you when you leave and drop it in the garbage bin or recycling etc. I think they teach this in kindergarten but it appears some people missed that day.

7) Related to #2 above, the choice of hotel is important. The closer the better (or at least the less walking you have to do). But there are other issues. I only have experience with the one I stayed at this year, Parc 55 Wyndham, but I'm pretty sure I won't be staying there again next year. The room was nice, clean etc, most of the staff were nice and helpful. My issues with the hotel were

1. the network is awful. Wifi or wired, it wasn't strong enough to keep iChat connections alive. And they charge $15/day ($50/week).
2. the included breakfast only includes pastries, you can add eggs and bacon for $25!
3. the elevators are extremely slow, taking up to 10 minutes to go up and down.
4. the TVs are locked down and prevent you from adding your own input, no connecting Apple TV or your laptop for example. That made testing some changes to Party Doodles impossible.

8) Since I'm Canadian and our roaming fees are insane, I wanted to pick up a local SIM card in order to be able to use data whenever I needed. I have an unlocked phone so it should have been easy. Eventually I went AT&T, $50 for unlimited voice and text, and $25 for 1G that they said wouldn't work on an iPhone and that they wouldn't refund the cost if I couldn't get it to work. After putting in the SIM card, it took all of about 30 seconds to switch the APN using the site: http://www.unlockit.co.nz/. The AT&T network has been great the whole week (Keynote excluded, but nothing was working there).

9) J.J. Abrams. Wow. He was a guest speaker for the Friday lunch session. And boy was his talk amazing. For one, he was by far the most entertaining speaker of the week, granted his content makes it easier, blowing up stuff is more exciting by itself than NSManagedObjects being accessed by the wrong NSManagedObjectContext. But his way of presenting was great, it almost felt like it was just me and J.J. in the room and he was telling me stories from his life. It was very interesting to hear how certain ideas/shows came to be due to other events in his life, in much the same way we move from app to app where the first app may inspire the idea for the second app. I'd love to go into more detail here, but it seems even this talk is covered by the NDA. J.J., if you're reading this (maybe Google Alerts brought you here), I just want to say thanks for the awesome and inspiring presentation.

10) One last point. Since it was my first WWDC, I wasn't sure when I should be here, so booked my flight for Saturday to Sunday. Getting here on Saturday worked out well, gave me some time to get to know the area and meet up with people for drinks etc. But next year I'll leave Friday night or Saturday morning. There wasn't much happening on Saturday or Sunday as most people have already left.

I'd say WWDC (I'm not yet cool enough to be able to call it "dubdub") was a great success this year. I can't wait for next WWDC 2013! It'll sell out super fast again next year, so be prepared...

If you haven't already, please download my free game Party Doodles, like us on Facebook, and if you like to hear me ramble, follow me on Twitter.

Ok, maybe not every single app, but if your app has any sort of data, then yes, you should add Dropbox support to the app. Certainly if the app is a tool of some sort, you understand that the user values the data that has been generated; but even if the app is a game, the user still values that data! If they've spent 5 hours to complete a tonne of levels, it's nice to have that accomplishment backed up, or available on a second device. This is where Dropbox comes in.

If you've been living under a rock and don't know what Dropbox is, it's a service that allows users to create a special folder on their computer that automatically syncs itself to the Dropbox servers and then any other computers also using the same account. This provides the user with a cloud based backup service (with a basic version control too). Using the official Dropbox iOS, Android and Blackberry apps, the user can access any of the files in their Dropbox account on the go. Sounds simple, and it is. So simple that everyone should be using it (especially since the basic service is free).

So how can you use this magical service in your apps? Dropbox provides an SDK for developers that lets you access a user's Dropbox account (with their permission of course). Now it's up to you to implement a solution to use it.

Before I go into detail on using the SDK (a future post), I'm going to suggest a directory hierarchy that we all follow. Remember that the root folder of the Dropbox is actually a directory on the user's computer that they're using. We don't want to clutter that folder with all kinds of stuff the user doesn't understand, they're likely to delete it.

One of the first apps I used that was Dropbox enabled was 1Password (An awesome app by the way). Their solution was to create a file called

.ws.agile.1Password.settings

in the root folder that only contained the location of their actual data. This lets users store their data wherever they want (provided it's still under the main Dropbox folder), and 1Password can still find it. There's a problem with this though, when you have lots of apps installed, all using a similar plan, you're going to have a tonne of junk in the root folder. Not user friendly at all. Not to mention, that while Mac OS X will hide a file starting with a dot by default, some of your users might not have switched from Windows yet and Windows will show the 'hidden' file in the folder, just waiting to be deleted.

My proposal, is that we create a folder in the Dropbox root called

.apps

as a central repository for third party app data. From there you use a reverse domain name system similar to your bundle id, but instead of dots, use new directories, and only use lowercase. So keeping with the 1Password example, they would store their data in

.apps/ws/agile/1password/

This will be consistent for their iPhone, iPad, Android, Mac OS X and Windows clients. All of their 1Password apps will be able to find the data regardless of system being used. Any data that is system specific can be stored further down the hierarchy.

This system should keep everything clean, organized and out of view of the user. Windows users will still see the .apps folder but at least it's just one folder and it's name should make it's meaning clear to most users.

Be aware that because you're now backing up your user's data to their Dropbox, they can now easily browse (and even modify) that data if they're so inclined. So make sure you protect this data if it shouldn't be seen or modified. For example, if you're game has 10 levels and you have to complete them in order to advance to the next one, don't record level completion in a simple format that lets the user effectively just check off that they've completed a level. If reading the data is ok (high score list etc), you can still use a simple format to store the info, just add some sort of validation to ensure the file hasn't been modified. A hash file will probably be fine for most simple cases (use some salt that you're keeping secret).¹

Update (added this paragraph that was accidentally cut during my editing phase): Why bother using Dropbox in your app when iTunes backs everything up during a sync anyway? Well there are lots of reasons:

• Not everyone syncs on a regular basis; shocking I know
• If a user deletes an app, it deletes the data too, next sync, the backup is deleted too, if the user decides to put your app back on their phone, they have to start from scratch
• Using Dropbox allows multiple devices to access the same data, play a game on your iPad, and continue later on your phone
• It may be your app, but it’s the users data, so making it easy for them to access is a good thing

¹ Note that the above point about checking for modified data files etc is vital even if you're not syncing to Dropbox, it's trivial for users to access/modify your data files through jailbreaking or even iTunes backups. Another issue is that the Dropbox folder is exposed to unknown other apps that might try to use the data contained within maliciously, scan for emails to spam, or account passwords etc. Those apps could be Windows malware etc so definitely encrypt sensitive data.

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.

I am a believer in the idea that a large subset of humanity enjoys helping one another to be successful, and that they become better themselves in the process. One way this occurs is with the Open Source movement. People that write software not for the profit that can be made with the software, but to give it away so that others can use it, as an end product to accomplish a task, or even to use as part of another project. This enables the next person to get a jump start on what they're working on in order to become successful faster than they would have been if they'd had to start from scratch.

Ideally the next person becomes a link in a chain so that others can benefit from their work and become successful themselves. Everyone does their part and everyone benefits.

Not all Open Source products are equal however. Just because someone releases their code as open source, doesn't mean you can do whatever you want with it. There is always a license of some sort attached to the code that governs what you're allowed to do. The Open Source Initiative site lists 67 different licenses that they've approved as meeting the existing community norms and expectations of what an open source license should be. Before we go any further, let me clarify that I am not a lawyer, I don't even play one on TV. So you should always consult your own legal council when dealing with legal matters.

Of all of the open source licenses, there are a few that are used more than others. The GNU General Public License (GPL), the Apache License, BSD License and the MIT License are the most popular. The latter 3 are very similar and impose the least restrictions on users of the code they license. The GPL imposes some very specific implications on users of the code it licenses and is the reason I'm writing this article today.

In simplified terms, the Apache, BSD and MIT licenses allow you to use the code they cover in other products and allow you apply a license of your choice to the new product. It doesn't have to be an open source license and so you're not required to provide the source of your product to others. You do have to include the appropriate copyrights for the source you've used that was created by others, and you do have to accept the fact that the source is provided to you AS IS, that there's no warranty of any kind given by the original creators of the code you're using.

The GPL however forces you to use it as the license for your new product. In this way, it has been described as a virus license since it effectively reproduces itself onto your product, and limits what you're allowed to do with your product. That is, you're forced to release the source code of your new product, and you must allow others to redistribute your product for free, in both source and object code. The philosophy behind this is that if you're benefiting from the work of others, you should be forced to share your work in the same way so that others can benefit. These restrictions make the GPL incompatible with the App Store, which means, as an iOS developer, you should avoid using any code that is covered by the GPL.

The reason that GPL code is incompatible with the App Store is the requirement that someone receiving the product be able to redistribute that product to someone else. Since all apps in the App Store have Digital Rights Management (DRM) applied to them, users are unable to directly share the apps with others. Because a developer is unable to give that right to the user, they are effectively barred from distributing their app through the App Store.

Just yesterday, this became an issue on the App Store as the popular app VLC was pulled by Apple due to complaints that it's presence on the App Store was a violation of the GPL. Even though the app was available for free, and the source code to the app was made available at http://git.videolan.org/ for anyone that wanted it, the DRM issue overrules and thus, no VLC for you.

As a user this is disappointing since the app allows you to play media files that no other app on the App Store, or built into iOS devices can play. But as developer, this is extremely alarming and should cause you to audit all the libraries you've used to ensure none are covered by the GPL, else your apps could suffer the same fate as VLC.

What's most disturbing about all of this, is that it seems as though, this is really just a silly technicality. The fact that a user is unable to share the exact binary they downloaded from Apple doesn't mean they can't share the app with a friend. The user can share the app just by sharing the iTunes link to the download (which is free), or alternately, provide the full source code. So the spirit of the GPL is still possible with the App Store, just not the letter of the GPL.

It would be possible for the Free Software Foundation (creators of the GPL) to release an updated version of the license to make it compatible with the App Store, but since they feel that all DRM is inherently evil, it's unlikely that will ever happen. Arguably, it might be possible for Apple to make DRM optional for certain apps, but that would require fundamental changes to the iOS architecture and might introduce security holes that make it easier to pirate apps. I don't see either side making any compromises here so your best bet, is to just avoid all GPL code and find (or create) alternatives that are licensed under the Apache, BSD, or MIT licenses.

This week, I'd like to throw something out for discussion. These are ideas that have come up in the course of real life discussions with other app developers. I need to preface this by saying that I have not implemented any of these ideas, and that I'm only putting the ideas out there to encourage you to think about and discuss alternatives.

It surprises me that in an ecosystem of 99 cent apps, piracy rates are still incredibly high. For this article the assumption is that as an iOS developer, you are able to detect at runtime, if your app has been pirated. There are multiple ways to do this, but the technical details of which are not required for this article so I'm going to skip them.

One of the requirements to install a pirated version of an iOS app on a device, is that the device needs to be jailbroken. If the device has been jailbroken, then certain security features will have been disabled. This makes it possible for apps to do things on the device, that Apple doesn't allow under normal circumstances.

This means, that a normally well behaved app, could be made to 'go rogue' when it detects that it has been stolen by the user. For instance, a stolen version of your app, could make a phone call to a charge per call phone number that charges the cost of the app to the users phone bill, therefore recovering the cost of the app for the developer. Similarly, the app could send a premium text message out, also charging the cost to the user's phone bill.

Now, I'm not proposing that you actually build this into your apps, as it's almost definitely the wrong way to go about building up your business¹. As iOS developers, is it not part of our job to educate users on the dangers of using pirated apps? The above ideas can be used in the same way we've warned against pirating desktop apps due to the dangers of viruses and other malware. Common users should be encouraged to live in Apple's walled garden as is indeed a great place for users and developers to be.

¹ A user that has pirated your app is still a potential customer and needs to be treated as such.

Today I'd like to discuss Apple's recent policy change with regard to app name squatting. If you're unaware of the policy, Apple says you must now submit your binary for an app within 120 days of reserving the name. If you don't submit a binary, you'll receive warning emails with 30 and 7 days remaining in your 120 day grace period. At the end of 120 days, if you still haven't submitted a binary, the app is automatically deleted by iTunes Connect and you're forbidden from using that app name again in the future.

The idea behind this policy is likely to prevent the ridiculous name squatting environment the exists with domain names. Personally, I don't believe that Apple has come up with a great solution to the problem though. 120 days isn't long enough for an independent developer working in his/her spare time to create a good quality app. And there's a known work around anyway¹, that just forces you to do an extra 5-10 minutes work per name to reset the 120 day count. So what has been accomplished? It makes it awkward for someone to register a tonne of app names and just sit on them, since the 5-10 minutes add up fast.

I propose that there is a better solution. Instead of an arbitrary time period to submit an app, why doesn't Apple limit each developer account (that is, per $99 fee), to an arbitrary number of incomplete apps. Lets say 10 for example. In my hypothetical world, you can squat on up to 10 names for each $99/year. Making app names cost about $10/year, similar to domains. But the domain ecosystem is a disaster you say. Well the difference is that with domains, there's a whois database. Everyone can find out who has registered a domain, and contact them in order to generate a sale. There is no current way to find out who has reserved an app name, and thus no way to buy the rights to a name. Which means, there is no market for buying and selling app names; crazy domain name ecosystem averted. The only people reserving app names will be those who plan to use them.

I'm sure there are problems with my proposal also, or that you have an even better solution. Please add to this discussion here.

¹ Rename the app that's about to expire to some gibberish, and recreate a new app with a new SKU and the original name you're reserving. Credit: Daniel Jalkut