The App Business Blog

Since the beginning of the App Store there have been complaints about Apple’s 30% cut, it’s app review rules and the enforcement of them. It’s an impossible task to create rules that will please everyone, but is it possible to create ones that are more clear, leave fewer gray areas and can endure over time?

When In-App Purchases were launched in 2009 it was initially targeted at selling digital content like books and magazines; I worked on the Zinio magazine reader and the Iceberg book reader apps at the time. Steve Jobs made the argument that when Apple brought a paying customer to a publisher Apple deserved to be paid 30% for it, and when existing subscribers paid they could do so outside of the App Store and Apple would not receive any commission.

In order to preserve this division of who brought the customer, Apple decreed that you could not link to your website or encourage customers to leave the app and sign up to your service outside the app. We’ve probably all had app rejections where app review finds a link or a mention deep inside the app that could be followed back to your website. Never mind that it does not take a genius to type in “Netflix” or “Salesforce” into a search engine to figure out how to sign up for their service. (Ironically, “Hey” may be an exception to this.)

For Apple to make good on their claim to bring customers to apps they need to provide a great way to discover apps in the App Store. The recent addition of curated content on the Today tab of the App Store app is great and I happily give Apple a commission every time a new customer finds one of my apps this way. But only a very small fraction of apps can be surfaced by Apple’s editorial team. The other major mechanism to discover an app is through search, and we all know what a joke search is on the App Store.

I would argue that most people find new apps via friends, social media and other articles outside the App Store. They all refer you to the App Store with a link so that you can install the app. This may give the impression that Apple served up a new customer to you on a silver platter, but in reality Apple had very little to do with the discovery. Therefore Apple’s original argument rings very hollow today and it’s not a stretch to see it more as “rent-seeking”.

The above history lesson skips over episodes like where you could offer purchases on your website inside a web view, but only for a brief time before you had to launch Safari to the same URL, before all such links became forbidden. So it’s not exactly been well defined and stable rules in this, the most consequential part of our apps: how we get paid.

Let’s try to find a clear line that divides apps that must use Apple’s IAP from those that don’t.

One one extreme end of the spectrum would be that all apps have to use Apple’s IAP for unlocking any feature or functionality in the app, and no alternative mechanisms for payment would be allowed. That is essentially what Apple says in paragraph 3.1.1 of the App Store Review Guidelines. But then this is followed by with several exceptions to this rule. So even Apple realized that this was too restrictive and it would needlessly bar many types of apps from the App Store.

The most curious exceptions are listed in section 3.1.3(a) under the heading “Reader” Apps. They include (and are specifically limited to):

• magazines
• newspapers
• books
• audio
• music
• video
• access to professional databases
• VoIP
• cloud storage
• approved services such as classroom management apps

It has been pointed out by several people that this list has a lot of overlap with paid services offered by Apple. Since each addition to this list means fewer payments to Apple there must be very special reasons for adding to this list. One obvious reason is antitrust: it looks really bad if your direct competitors are forced to pay 30% of all their revenues to you just for the privilege to be on your platform. So adding more app categories to this list is a good thing for app developers, but it violates our goal of finding rules that do not morph over time. If Apple were to hypothetically launch a paid fitness app/service in the future, would that be added to the list of reader apps? Would existing apps of this type have this new rule applied retroactively, or the next time they submit an update?

SaaS services like Salesforce and Slack are not included in the list above. So why can they offer an app that has no functionality unless you already have an account with them? Do they fall under the category “approved services”? Is there a secret list of approved services?

I would argue that none of the above rules fit the criteria of being clear, encompassing and enduring. The further you move away from “all”, the more exceptions you have to make and the more gray areas you create. And that’s without examining all the one-off exceptions that Apple is known to have made with some notable companies.

Let’s approach the problem from the other extreme: all companies can do whatever they want to collect payments. Apple’s IAP system is just one payment system developers can choose from, and it has to compete for business on its own merits.

Apple’s core argument here is that a free-for-all system would more confusing and more risky for consumers. Some app developers are very crafty and it would not take long before devious scams would appear on the App Store, for example apps whose sole purpose is to collect credit card numbers. How would Apple avoid responsibility when an app defrauds customers and Apple approved the app for inclusion on the safe App Store?

A solution could be to have the payment systems be audited and approved by Apple or a third party organization. Then each developer would choose the payment system that best fits their business model. Apple would no longer have to categorize apps and decide which ones need to use which system. With competition between payment systems that should make antitrust regulators happy as well. Apple could probably justify taking a small fee from all transactions as payment for letting lots of electrons pass through the systems they maintain. It would of course not be anywhere near 30% though.

Will Apple make any changes to their rules without being forced to? In 2019 Apple paid out $39B to app developers. That means their 30% cut was likely more than $10B (accounting for some 15% deals and that some apps are paid up front). Most businesses would fight tooth and nail to keep that much annual revenue. Even if it means semi-regular firestorms in the press and antagonizing the developers who do most of the work to earn that revenue. For now it seems that Apple is content to be just like most businesses in this regard.

written by Nick

The German site ifun.de noticed that Apple recently changed their iTunes Terms and Conditions for several (all?) EU countries. The changes include several new paragraphs related to “right of cancellation” and it mentions a 14-day period within which you can cancel your order and receive a refund, without giving any reason.

9to5mac seems to have been the first U.S. site to pickup the story and they ran with the headline “Apple introduces 14-day no questions asked refunds for App Store & iTunes in EU countries”. This was quickly picked up by many other sites and caused a lot of buzz on Twitter.

So it must be true then?

The iTunes T&C were indeed changed for EU countries on December 16. You can read the new U.K. version here. The new paragraphs in question are conveniently placed at the very beginning of this very long legal document. Here’s the smoking gun:

Right of cancellation: If you choose to cancel your order, you may do so within 14 days from when you received your receipt without giving any reason, except iTunes Gifts which cannot be refunded once you have redeemed the code.

Compare that to the U.S. version which succinctly says:

All sales and rentals of products are final.

Very interesting. And a significant change to how business is currently done on the App Store. Could this finally be the introduction of free trials that so many developers have asked for? But if that is the case, why introduce it as a change to the T&C and do it during the holiday season? Apple is certainly not known for being proactive in their communication with developers, but this borders on the Christmas Eve document dumps that governments like to do when they don’t want anyone to notice.

But if you bother to read a bit further into the T&C document, you quickly find this paragraph:

Exception to the right of cancellation: You cannot cancel your order for the supply of digital content if the delivery has started upon your request and acknowledgement that you thereby lose your cancellation right.

Given how the App Store works with downloads beginning immediately when you purchase an app, this change is really only interesting to lawyers and EU commissioners who are pushing a new directive on consumer rights.

Nothing new here. You can go back to your holiday vacation and glögg.

But since I have your attention, let’s do a thought experiment: What would happen if Apple suddenly did implement a 14-day no questions asked return period for iTunes?

Who would benefit from this?

Consumers obviously. But I also think that many developers would make more money as a result of such a change. If you have an app that is expensive, it seems very likely that more people would be willing to give it a try if they know that they can easily get a refund if the app is not right for them. This is the argument put forth by proponents of time limited trials in the App Store.

When you shop in the App Store you know that you are inevitably going to buy some duds: apps that were not what you expected, apps that are buggy, apps that were totally misrepresented in the App Store description, etc. When apps only cost $0.99 it’s easy shrug off the bad purchases. The total price you paid to find an app that you end up using is still pretty low. However, if the risk of purchasing a “bad” app is taken away, then that could lead to an overall increase in App Store prices. The difference for developers is that the good apps will get all the money instead of it being spread out accross several not so good apps. This is a good thing in my opinion.

Who would become the losers?

Developers of bad apps are likely to suffer economically as a result of easy refunds. Their refund rates will skyrocket and the business model of flooding the App Store with crap will crumble. I would not cry for them.

Unfortunately some really good apps could fall victim to this change as well. Think of apps that you “finish” within 14 days. Many casual games fall into this category. Event specific apps too. Perhaps some travel related apps, e.g. after your short vacation trip you may not “need” a city guide app anymore. Of course it’s not right to fully enjoy an app for 13.9 days and then request a refund. But some people would of course abuse this.

Open questions

• If an app is refunded, would it be removed from the customers iTunes account or can the customer continue to use the app?
• Would this only affect the initial app purchase, or In-App Purchases too? I’m guessing only the initial app purchase as it would be impossible for Apple to “roll back” purchased features and benefits inside apps.
• Would this change only pertain to apps? The Terms & Conditions are for all of iTunes, not just the App Store portion. What about ebooks, music and movies? I think movies would be especially vulnerable to a 14-day return period. It’s unlikely that it will take you 14 days to watch a movie. And if you “didn’t like” the movie is that reason enough to get a refund?

How would this affect you?

If Apple were to implement a more liberal refund system, then you should keep an eye on  your refund numbers in iTunes Connect. In the sales report you can set a filter for Transaction Type = Refund. You have probably seen some of these in the past as Apple has always had a limited refund policy in place, it was just a lot more difficult to use.

In all likelihood you would see the refund number increase initially after a new refund system was introduced. I wouldn’t panic immediately. People are probably going to try this new system in the beginning to see if it really works. Then I think many people are going to promptly forget about it.

Should you pull your app from sale in the countries where the refund policy was introduced? That seems like a foolish reaction. Even if your net sales after refunds is lower than your sales were before, they would still be greater than the $0 you’ll make from no apps for sale in those countries.

If my guess above is correct and IAP would not be subject to refunds, then maybe a change will finally push you over to switching your apps to free download with IAP to unlock all features. Interestingly the reverse is also true: if it turns out that apps that are paid up front convert better than free + IAP, then it should be worthwhile launching a paid app as well.

Why is Apple not doing this?

A Machiavellian approach would be to implement this under the guise of “EU is forcing us to do it”. And if things don’t go well, then they can blame the EU directive. If it’s a success, then they can take credit and roll it out to other countries too.

If nothing else, rolling out a new return policy just in the EU would make for a controlled experiment to determine if trials are a net positive for apps: You can compare your net sales in the EU before and after this change, and you can compare with other regions of the world that do not yet allow for easy refunds.

Apple should view this as a good change for consumers, and Apple usually takes the side of consumers, especially when they can use that club against their competitors. As far as I know the Google Play Store still only offers a 2-hour return window for apps.

As this news flash showed, the thought of instituing a 14-day return period caused a lot of anxiety among developers. But overall I think this would be a positive change for the best developers. And that would definitely be in Apple’s long-term interest.

written by Nick

Things we expected:

• WatchKit makes extensive use of existing technologies such as extensions and notifications.
• The initial release of WatchKit was expected to be more limited in capability with full native apps only being possible later in 2015. That said, this release was more capable than we dared hope for.
• You can use both Objective-C and Swift to develop apps for Apple Watch. Apple recommends that you use frameworks to share code between your container app and extensions. However, as far as I know in Xcode 6.1 it was not possible to create Swift frameworks for use in extensions. Maybe that has changed in this release.

Things that I thought were surprising:

• All your code runs on the iPhone and not on the watch hardware. The watch basically acts like a remote terminal: the code on the iPhone sends commands to update the display and receives back messages of the user’s actions. This is a really clever way to limit the power consumed by the app on the watch. To further reduce the amount of communication needed between the watch and the iPhone, all your UI elements are packaged up in the watch app extension and sent to the watch when the app is deployed.
• No auto layout. Apple has pushed auto layout hard for several years as a solution to dealing with different screen sizes. The Apple Watch seemed like a great test for this paradigm with its much smaller screen. But I’m guessing the reality of battery life won the argument in favor of something much simpler. I just wish the new system didn’t bring back those old memories from Java Swing…
• Entirely new UI controls. Everything is new in WatchKit. Some things like labels and buttons have some resemblance to our dear friends UILabel and UIButton. But tables work in a totally different way from UITableView, for example. Nothing earthshattering, just more new API:s to learn.
• Many new interaction methods. Nilay Patel at The Verge counted 15 different ways to interact with an Apple Watch. Many of them would be difficult to discover; you just have to know them. Of course Apple is building on the knowledge that watch owners already have acquired from their iPhones. It still behoves you to follow Apple’s conventions in your own apps so that your customers will know how to use them. Bow to the HIG.

What is the app business opportunity?

WatchKit as it stands today is clearly geared towards creating extensions to existing iPhone apps. (I’m intentionally specifying iPhone here as it does not appear that the Apple Watch will pair with an iPad. In terms of everyday use of the Apple Watch, that makes perfect sense. If the iPod touch will be supported is an open question.) So if you have an existing iPhone app that could benefit from displaying small and time relevant pieces of information on a watch, then you should definitely consider adding this fuctionality. Just like supporting the different screen sizes of the iPhone is necessary for high quality apps, adding Apple Watch support will soon be too. Imagine if an Apple Watch owner is choosing between your app and a competitor’s, and the latter supports Apple Watch but you don’t. Don’t make it this easy for your competitors to win over customers.

App developers with existing apps defintiely have an advantage in bringing Apple Watch extensions to market, since they can focus on just the Apple Watch extension part of development. But that doesn’t mean you should throw in the towel just because you don’t have an existing app that fits this mold. On the contrary. Existing apps will focus on their exising functionality and extending it to the watch as Apple recommends. This will lead to a lot of very similar Apple Watch extensions. This is a great opportunity to stand out by doing something different with an app that is concieved with the Apple Watch in mind. What is currently impractical to do on your iPhone, but would make a whole lot more sense in a watch or wearable context? Looking for some crazy ideas? Checkout the hackathon happening this weekend.

Games?

Games are a great business opportunity on the iPhone, so what about games on the Apple Watch? The current WatchKit APIs are clearly not designed for games, but never underestimate the ingenuity of developers.

You can for example preload images in the bundle that is deployed to the watch. (Apple does this in the Lister sample app where they include 360 separate images to show all the possible states of a progress circle.) The app can then very quickly display the appropriate image. Apple says you can cache about 20 MB of images in this way, which would lead to a game with at most a few thousand distinct pre-rendered UI states.

Another option might be to generate the image dynamically on the iPhone and then send the generated image to the watch. This would allow you to generate any image, but the bottleneck would instead be the speed at which the image can be sent to the watch. As far as I know Apple has not published any specs for this, and it’s something that’s impossible to test with the simulator. This reminds me of the early days of developing for the iPhone and iPad without being able to run your code on actual hardware. There will be many surprises when the soft bits hit the hard reality of resource constrained hardware.

App Review

When coming up with new and innovative app ideas you always have to consider App Review. Will they approve the app that you have spent months of development on? With a new platform like the Apple Watch there is no past history to use as guide. With iOS 8 extensions Apple did add several new review criteria at the very last minute. And there have even been changes after that, affecting apps that were already live on the App Store. That has made many developers unhappy, understandably so because they spent a lot of time developing extensions which Apple suddenly did not allow. I’ve seen developers asking in the forums about clear guidelines on this. If you are considering an idea that you think might fall in a grey zone. File another Radar requesting the app review guidelines for Apple Watch to be published sooner rather than later.

Can customers pay money for Apple Watch apps?

Let’s first look at the technical aspects of selling “Apple Watch apps”. In their current form apps for Apple Watch are extensions embedded in an iPhone app. This is very similar to how Today and Sharing Extensions are delivered. This means that you cannot sell and charge for your Apple Watch extension separately. It is always part of a container iPhone app, which is what your customers will find and download from the App Store. The Apple Watch extension will always be available to a customer who installs your app. You cannot control this by with an In-App Purchase. Also, you cannot make In-App Purchases from the Apple Watch. But since the Apple Watch App Extension can communicate with your container app, you could have an In-App Purchase feature in that app which will unlock and enhance functionality for the watch app. Some keyboard extensions employ a similar mechanism for payment.

The other side of this question is if Apple Watch owners are willing to pay for apps for their new toy. See my earlier blog post for my speculations on this.

Should you wait?

With all the limitations of the first version of WatchKit are you better off waiting for the opportunity to develop real native apps? I would say waiting is a wasted opportunity to gain experience. All third party developers have the same limitations, so your customers will not expect your app to be fully native at this point. Build what you can, learn and get feedback from customers. Iterate. When native apps are possible you’ll be in a much better position to take advantage of the new capabilities. If you have a million dollar idea that will reqire a native app to fully blossom, then you could use a different idea for your learning project lest you reveal too much of your idea too early. But as I’ve said here many times: ideas are nothing, execution is everything. And you only get better at executing by doing it.

The Future

The architecture of WatchKit seems to be heavily optimized for low battery usage on the watch. This is smart because poor battery life will be a product killer for consumers. But how are they going to transition to native apps running on the watch in 2015? Obviously there will be restrictions on what a native app can do, but still it seems that there will be orders of magnitude differences betwen the current WatchKit architecture and native app code running on the watch when it comes to resource usage. On the iPhone, Apple was able to rely on advances in hardware to make new software features possible. Multitasking is one example which was not possible on the earlier hardware generations. But it seems unlikely that Apple will release a second generation Apple Watch in 2015. Everybody knows that there will be new and improved models coming out over time. That’s how Apple makes their money. But if you buy an expensive 24K gold Apple Watch in the first quarter of 2015 it would be harsh to see a second generation with more software capabilities come out within six months.

What should you do next?

If you haven’t done so already, watch Apple’s Getting Started with WatchKit video, download all the related documentation and read it. Then it’s time to get the latest Xcode beta and start playing with the sample code. Note that if you are having issues with getting the Lister project to run, see the developer forums for some helpful advice.

While the Apple Watch simulator in Xcode is cool, it is very difficult to imagine what it will be like to wear that screen on your wrist. If you are serious about creating really imaginative apps for the Apple Watch then you should invest in some wearable hardware. It’s unlikely that you’ll score a prototype device from Apple, so you’ll have to make do with some of the not so good alternatives already on the market. I don’t think the exact features of the device(s) that you select matter that much. It’s more of a mindset and getting your body used to glancing at your wrist. Especially if you are like me and you haven’t worn a watch in decades. What type of information would you want to have glancable? What are some situations where you don’t want to pull out your iPhone? How large must the UI elements be in order to be glancable?

More reading

Apple’s WatchKit homepage
This should be your staring point. Begin with the Getting Started video. The pace is a bit slow at times, but it has great information. Then there are plenty of links at the bottom of the page to explore further.

iMore’s WatchKit Overview by Serenity Caldwell
A great summary of what consumer can expect from WatchKit apps.

Underscore David Smith has been seriously preparing for WatchKit for a while and as usual he documents his path and thought process.
Expectations for WatchKit
David Smith on WatchKit
Developing Perspective podcast #201: On Expedition.
Developing Perspective podcast #204: Delightfully Pragmatic.

Accidental Tech Podcast #92
Marco Arment, Casey Liss, and John Siracusa talk about WatchKit.

WatchKit: Initial Impressions by Ray Wenderlich
A good overview of the technical capabilities of WatchKit.

A day with WATCH
A deeper dive into the architecture and the classes of WatchKit.

written by Nick

Right after WWDC I wrote a short note about a new feature in iTunes Connect that allows you to request promo codes for app updates and how you could use those promo codes for testing the final app binary before it’s released on the App Store.

With the release of the new iTunes Connect UI almost everything looks different, but the same features are there. So here’s a follow up with screen images and step by step instructions.

1. Manually release the app

You should always, always release your apps manually instead of having them be released automatically as soon as they are approved. Odds are that your app will be automatically released on a Friday or Saturday evening and then your weekend may be spent answering support emails. So for your own sanity, release apps when it’s convenient for you. Manual release is also a requirement for this promo code testing trick to work.

2. Submit your app for review as usual

Nothing new or different here. If you forgot to select manual release you can still change this while the app is waiting for review.

3. Pending developer release

When the app has been approved it will be in the state Pending Developer Release. At this point the Promo Codes link appears at the bottom of the app details page.

4. Request one or more promo codes

This is the same old process you have probably used in the past to request promo codes for press contacts. Make sure you read the rules so that you do not violate the contract governing how promo codes are to be used. I’m not a lawyer, so I cannot provide advice here.

5. Download your app using one of the promo codes

Downloading an app using a promo code is usually a straightforward process. But in my experience when the promo code is for an update, iOS sometimes gets confused. It’s not consistent. But sometimes the App Store app shows an Update button right after the download is complete. It’s not clear to me if tapping the Update button will download the update you really want, or if it will “update” to the latest public release available on the App Store. Sometimes the whole process fails and my update is nowhere to be seen. So don’t be dismayed if need to burn more than one promo code to get the binary you want downloaded onto your device.

If your app saves any data you should test the upgrade scenario where you have a prior version of the app installed on the testing device. Upgrading from the App Store in this way is what your customers will experience and this is very different from when you are running and upgrading the app from Xcode.

6. Reject or release

If all testing goes well you can release the app at your convenience and in coordination with your release campaign. Tap on the Release This Version button at the top right of the app details page.

If during your testing you find any showstopper bugs you can reject this binary instead of releasing it. Click on the Cancel This Release button in the Builds section of the app details page.

Remember that Apple keeps a detailed history on all status changes of your apps. So don’t reject the binary after it has been approved by app review unless it’s really necessary. When you cancel the release you’re telling the app review team that they just spent time reviewing your app for no good reason since that version they reviewed will never see the light of day.

So don’t use this method as your early stage QA. Use it as your final, final confirmation that nothing went horribly wrong in the very last build step. Give yourself the peace of mind knowing that your customers will not face a botched binary when they go to update your app.

written by Nick

WatchKit has not yet been released but Apple said that it would be released to developers in November. I just recieved a note that a hackathon has already been planned for November 22-23. That seems a bit daring given that software is not always ready and released on time…

It sounds like fun though! Unfortunately I will not be in the San Francisco area that weekend. If you are, check it out:

RSVP

November 22, 2014 The Workshop, 4 – 7 PM, San Francisco, CA
November 23, 2014 WatchKit Hackathon, 9:30 AM – 7 PM, Mountain View, CA

written by Nick

The largest mobile operator in the United States, Verizon, is not participating in the Apple SIM program. As I wrote two weeks ago, the Apple SIM takes power away from the mobile operators and makes it easier for customers to select, and later switch between carriers. So I understand why Verizon does not like the Apple SIM. But it’s very unlikely that Apple will suddenly change their mind because Verizon is holding out. Apple historically takes the side of customers and customer experience, and plays hardball with the carriers.

iPads that you purchase anywhere, except for at an actual Verizon store, will come with the Apple SIM. Therefore in order to activate most iPads on the Verizon network you need to go to a Verizon store and get a Verizon SIM. I’m guessing that you could also call them and navigate through their phone tree in search of someone who knows what an Apple SIM is and why you want to replace it. Then you need to physically swap the SIM cards before you can finally activate the iPad on the Verizon network.

Why would you want to make it this difficult for customers to give you money? Yes, your diehard fans (or more realistically, customer without a real choice) will jump through these hoops. But these customers are yours anyway. If you were to advertise a competive data plan alongside the other operators that work with Apple SIM, then you just might gain new customers.

Another Apple innovation, Apple Pay, is also causing companies to refuse to take customers’ money. A “competing” mobile payment network has ordered their retailers to disable their existing NFC terminals just so that customers with an iPhone 6 cannot use it to pay at their stores. (I’m deliberately placing “competing” within quotes because to compete you actually have to be in operation. And from what we’ve seen of their plans, it looks like their launch will be a stillbirth.)

This is again about power and owning the customer; specifically owning the customer’s data. There is enough money in mining customer data and avoiding credit and debit card processing fees, that these retailers are willing to go to extreme measures to prevent a better payment method (for customers) to get a foothold in the market. Short-term that might work for them. When you get to the cash register are you going to walk away from your cart just because you can’t pay with your iPhone 6? Probably not. But if you have two competing pharmacies in town and one offers your preferred payment method and the other one doesn’t, which one are you going to pick?

Acquiring new customers is very expensive. Keeping existing customers by keeping them happy is a much better strategy. Don’t make it difficult for your customers to give you money. That is a very shortsighted strategy.

written by Nick

Debug is a podcast that I highly recommend. It’s a conversation about developing software. It’s not primarily about code and programming techniques, but more about looking at development at a higher level. So even if you are not a hardcore programmer I think you’ll enjoy it.

Recently they had a two part series with Don Melton, former Director of Internet Technologies at Apple, and Nitin Ganatra, former Director of iOS Apps at Apple. I found it fascinating to hear about the early days of development of iPhone OS. How do you come up with new user experience paradigms for a touch screen device that nobody has any prior experience with and still make it easy to use? Fascinating stuff.

• Debug 47: Melton & Ganatra episode I: Demoing software to Steve Jobs
• Debug 48: Melton & Ganatra episode II: Understanding Apple

written by Nick

The new announcements were pretty much as expected. A few things stood out to me.

iOS 8 Adoption

I thought it was interesting that they put up a pie chart showing the iOS 8 adoption numbers when they are so much worse than the adoption for prior iOS releases. To compare favorably with Android this year they had to combine the numbers for iOS 7 and 8.

Why does Apple care about the adoption numbers at all? So much that they dedicate time and a slide every year to it. Is it just to get a jab in at Android? Apple really cares about selling new devices. Having the best OS in the market on new devices justifies the expense of releasing new iOS versions each year. Allowing customers who purchased an iDevice in the last year or two to upgrade to the latest iOS version gives customers peace of mind that they are still being taken care of. But if those customers chose not to upgrade, Apple couldn’t care less. It’s of course a big pain for us developers to support older versions of iOS. Apples own free apps like Pages and iMovie are not in the same boat. They just need to work great on the latest iOS in order to sell new devices.

I thought it was noteworthy that Craig Federighi admitted, albeit in a humorous way, that iOS 8.0 was less than stellar. That shows awareness at the highest levels of Apple. Awareness is the first step to fixing a problem.

iPad Lineup

Actively selling 56 different iPad models seems very unlike Apple. In the iPhone lineup, the options have always been quite clear. Historically you bought the current model with all the new fancy features, or you could save money and buy the prior year’s model. This year you pick the iPhone screen size that fits you. It also used to be a simple size choice for iPads as well. But now, how do you choose? As developers and app business owners we of course collect them all! (Under the thin guise that we need them for testing…) But what would you tell a friend who asks for your advice on which iPad to get?

And what’s up with selling a 16 GB iPad in 2014? Other than greed? Granted that decision was made many months before Apple was criticized for the same thing with the iPhone lineup. And before limited memory hampered the upgrade rate for iOS 8. In hindsight I think this decision will be looked upon as one of the less insightful ones in recent Apple history.

Old Models Still For Sale

From an app development perspective having these old devices still for sale is problematic. Since we can’t prevent the sale of an app based on specific models you always have to develop for the lowest common denominator. In this case it’s the original iPad mini with the A5 CPU and a non-retina screen. Also known as the iPad zombie.

Don’t get me wrong, the iPad mini is an amazing device that was unthinkable just a few years. But technology moves forward at a dizzying pace. And in this case I think Apple should revert to its more aggressive self and retire the older devices. That will make customers’ experience so much better when they try to use cutting edge apps.

M8

I thought it was curious that they included the M8 motion chip in the new iPad Air 2. Are people going to use an iPad to count the number of steps they walk during the day? But there are probably better use cases for games and for image stabilization with the camera.

Camera

Apple is really embracing the trend of using an iPad as a camera.

Touch ID & Apple Pay

The new iPad is going to be a shopping machine for the upcoming holidays.

Carrier Aggregation

This was mentioned in a single sentence when Phil Schiller explained how the new iPad Air 2 is able to get 150 Mbps speed on cellular. I was intrigued. Would that require multiple SIMs in the iPad?

Part of the answer came when the product specs went up on the website. Take a look specifically at the Apple SIM section. This is a huge innovation. One that will further diminish the power of the carriers.

In the future the purchase of your device will be even more disconnected from the selection of a carrier. You will be able to switch carriers effortlessly without having to track down a new SIM card. International travel will be much easier. You bring your device and when you get to your destination you just pick a carrier and a plan from the competing offerings. Carriers are going to hate this because it removes several of their lock-in levers and actually promotes competition between them. But they don’t have a choice unless they want to walk away from a huge chunk of profitable customers.

I wonder why Apple SIM is not in the new iPhone 6 models? Perhaps Apple wanted to do a softer launch with the iPad before hitting the carriers with this new brave world for the much more important iPhone.

Update: It turns out that carriers can still play shenanigans with the Apple SIM. AT&T for example will lock the Apple SIM to their network as soon as you activate their service on your iPad. Talk about incentive to not use AT&T! Sprint apparently plays a different game where an iPad that you buy in one of their stores does not come with the Apple SIM at all. Instead you get a “legacy SIM” that, surprise, only works on the Sprint network.

Retina iMac

I remember sitting in the auditorium at WWDC when the retina MacBook Pro was introduced. I think every developer in the room wanted to click the Buy button right then and there. The new iMac has a similar drool factor for developers. Very nice!

Apple Watch

Tim Cook of course iterated how very, very excited they are to release the Apple Watch in early 2015. I found it interesting that it appeared that he was only wearing the Apple Watch during that particular segment of the event. Shouldn’t the executives and the developers wear the prototypes around the clock?

We developers are of course very excited that WatchKit will be released in November.

It’s been a long time

I still don’t know what the title of the invitation means. The only hardware that saw a refresh for the first time in a long time was the Apple Mini. And that was appropriately given just a few minutes of stage time. The title could be an inside joke, perhaps referring to the fact that it wasn’t that long since the big September event. I think Apple is just having fun with Apple watchers who try to read the tea leaves and parse everything that comes out of Cupertino.

written by Nick

Amazon is introducing a new Kindle device: Kindle Fire HD Kids Edition. The hardware is nothing special to write home about: A run-of-the-mill Android tablet with a 6″ screen. What makes it special is the complete package that includes a kid friendly case, a no questions asked replacement warranty, and a year of Amazon FreeTime Unlimited. What Amazon is telling parents (and grandparents) is that you can buy this package and then never have to worry about the device breaking or worry about buying apps. Everything is included for $149. I think this will be bestseller for the holidays.

If you develop apps for kids you should take notice of this new device. Make sure your apps are available on FreeTime Unlimited.

Unlimited apps is of course Amazon’s way to devalue apps similar to what they have done with Kindle books. Make no mistake of what side Amazon is on. Hint: it’s not app developers or book authors. But can you afford not to participate? If your competitors are on Unlimited, customers will select their apps over yours.

One way to reduce the risk of selling on the Kindle platform is to do multi-platform development. I think this can work especially well for kids educational apps. Take a look at Unity for this. Since version 4.3 they have a complete system for developing 2D apps. For an introduction to Unity check out Brian Moakley’s epic video tutorial series on www.raywenderlich.com.

written by Nick \\ tags: Amazon, Kindle

Much has been written already about Apple’s event this past Tuesday. I will try to not repeat everyone else’s opinions, but instead focus on what the news means for you as an app business owner and an app developer.

iPhone 6

Let’s start with the least surprising announcements. The new phones were almost exactly what we had expected.

There was an interesting change in how the iPhone 6 Plus renders views to its screen. An app sees a native screen resolution of 1242 x 2208 but the resolution of the screen panel is just 1080 x 1920 pixels. The phone hardware downsamples from the larger screen buffer to the physical screen. This doesn’t sound like a good idea, but people who have seen it in real life claim that the result is not a fuzzy screen. I think we have reached the point where pixels are now so small that you cannot see any imperfections resulting from this downsampling. For app designers it means that you should not try to draw single pixels lines or depend on your UI to be pixel perfect. The trend away from skeumorphic pixel perfect designs has been very clear since iOS 7, so this should not be news. Focus on the content of your app, and it will look beautiful on these new HD screens.

Introducing this downsampling technique also provides a lot more flexibility for Apple in future screen sizes. They are no longer constrained to just 2x and 3x multiples of the original iPhone screen from 2007. The screen sizes seen by the app can remain nice multiples so developers don’t go totally insane when creating image assets for apps. Then Apple can pick an appropriately sized screen panel for the device they want to build.

Of course there are now two more screen sizes to deal with. The writing on the wall has been written with flashing neon paint for quite some time. By now you should be using auto layout and be getting familiar with the new screen size classes. If you have to maintain compatibility with iOS 7 (and earlier) then there will be pain.

I have yet to research if it’s possible to include/exclude specific iPhone models from installing your app. It seems that the old iPhone/iPad selector is too crude of a switch now that we have an iPhone that is quite close to the iPad mini size. I can imagine iPad only apps today that would work on the iPhone 6 Plus, look ok on the iPhone 6, but be totally unusable on the smaller iPhones. (Before you say “adapt the layout to the screen size”, imagine an app that displays a PDF file or any other asset that has a large fixed size.)

The new phones look like they have new keyboard layouts to make good use of the extra screen space. If you are developing a keyboard extension then you have some extra work to do. Maybe that was why no keyboard was visible in the variable sized simulators in Xcode betas.

Both iPhone 6 models support the new, more efficient H.265 video format. If you are streaming video to iPhones you should definitely check the device type that is requesting the video stream and where possible serve an H.265 stream since that will considerably save bandwidth for you and provide a better experience for the customer. Since the old iPhone devices do not support this new format it’s too early to replace any embedded video files you may have in your app.

Apple Pay

The real story here is about security and not about convenience. Physical credit cards and credit card terminals are in a sorry state in the United States. It’s probably the only country in the world where just the knowledge of the numbers on the card are sufficient to make a purchase. Most civilized countries require a chip on the card which proves to the terminal that you actually have a valid card and not a generic piece of plastic that you just magnetized with data from a credit card dump. Apple Pay is at this level basically a secure chip to guarantee the authenticity of the payment card.

In 2015 merchants will become liable for fraudulent transactions made at their POS terminals. Therefore they will become reluctant to take the old magnetic stripe cards in the future. iPhone 6 customers will be very welcome because the risk of fraudulent transactions will be much, much lower. Payment terminals will be replaced because of this shift in liability and new ones will include NFC. Apple’s timing here is perfect.

Apple likes to make plastic obsolete (floppy disks, CDs and DVDs, etc) and that’s really what they’re doing with Apple Pay. They are not replacing banks or credit card institutions, they are working with them. Apple brings trust and security to the equation in a way that no other company has been able to offer to the industry before. And it doesn’t hurt that they bring along a few hundred million highly valued customers…

Reports indicate that Apple is receiving a %0.15 fee on all transactions that go through Apple Pay. And it’s almost entirely profit for Apple. Of course they have spent years building up their products and infrastructure to put them in a position to be able to offer this service. Another example of Apple’s long term thinking.

What’s in it for you as an app business owner? There will be an API (in iOS 8.1) to add Buy buttons inside your apps. This will make it very easy for you to sell physical goods inside an app. You just add the Buy button and Apple takes care of the whole checkout process. So you can sell fluffy toys of your game characters easily from within your app. Or if your app requires a hardware accessory, then your customers no longer have to find your website to place their order.

If there’s some form of affiliate tracking capability built into Apple Pay, then you could earn extra revenue in your apps by selling other peoples’ stuff from within the app. Many podcasters print custom t-shirts and sell to their fans. Say you have a podcast app you could easily have buy buttons for such real goods in the app. This is a huge revenue opportunity for apps.

While there will soon be an API for Apple Pay, there will not yet be an API to access the underlying NFC hardware. Apple’s usual pattern is to introduce new hardware, keep the APIs internal for a while to better formulate a public API for 3rd party apps. The Touch ID sensor is a perfect example of this. If you have specific use cases in mind for NFC let Apple know via Bugreporter. See this article for some ideas of what they’re doing with NFC over in Android land.

I’m assuming that Apple will not allow you to sell digital items with Apple Pay. They still want their 30% on In-App Purchases, not the 3-6% that you would pay for a credit card transaction. I foresee some interesting gray areas and boundary drawing here in the future.

Apple Watch

Two things struck me about the presentation of the Apple Watch.

1. There was no explanation for why you would want the Apple Watch before it was revealed. Compare this to the extensive preamble both in the iPhone and iPad introductions.
2. The presentation and especially the demo was very geeky. Definitely more directed to a tech audience than the invited fashion editors.

I think both items stem from the fact that Apple doesn’t really know what the Apple Watch will become. Just like they didn’t really know how the iPhone and iPad would eventually be used. (Installed any web apps recently?) They showed some of the things they have come up with internally that they thought seemed cool. But with Apple’s secrecy the developers in the know could probably not walk around all day with an Apple Watch on their wrist to experience daily life usage. Apple has a great advantage because of the developer community who loves to take their beautiful devices and make them magical with new software. This is of course a great opportunity.

With the top of the line watches probably costing many thousands of dollars, you would think there could be a profitable market for high-quality apps. At least I can hope for a higher bar when it comes to UI design. Please, if you are going to develop for the Apple Watch, invest in good UI and UX design. Nobody is going to want to show off their new solid gold watch with crappy looking apps.

How do you get started as an app developer with a great idea for a watch app? First get familiar with iOS 8 Extensions. It seems very likely that extensions will be the way apps are delivered to the Apple Watch. Build a simple today widget with a very simple UI and limited interactivity. Now strap your iDevice to your wrist and you’re up and running. 😉 At least that should give you a sense of WatchKit Glances and Actionable Notifications. Native WatchKit apps will coming later as well, opening up more possibilities.

One of the more intriguing hardware aspects of the Apple Watch is the large button below the crown. It was barely mentioned in the keynote and the only thing it appears to do is bring up the communication feature on the watch. Apple must really think that will be an important aspect of using the Apple Watch. Don’t we have enough ways to send messages from person to person on our iPhones? Is it a game changer to be tapped on your wrist instead of having your phone buzz in your pocket? It’s probably one of many things that you cannot theorize about; you have to try it out in real life. Which is why all of us developer will line up and by an Apple Watch as soon as it goes on sale.

Why is it called Apple Watch and not the much rumored iWatch name? I think it’s obvious. Apple is one of the most valued brand names on the planet. It’s synonymous with fine design and high quality. The letter ‘i’ does not connote any of those qualities. An iWatch would be placed in the same mental category as Swatch.

Wait, There’s More

Apple really played up this event like few other events. It appears that Apple sees the Apple Watch as a seminal product for the company. However I have a hard time seeing Apple Inc. hanging its future on becoming a watchmaker, even if it is the coolest watchmaker on the planet. With all the build up and all people they have hired in the last year, there has to be more. I’m guessing that this is just their first foray into wearable computers. Just like Apple introduced the iPhone before the iPad because people immediately understood what a phone is; people have an existing mental model for a watch. I can see how there could be future, specialized variations of the watch concept. For example a medical device with more sensors. And there could be computers without a display that act as accessories in the Watch/iDevice ecosystem.

In Closing

With these new announcements, iOS 8 and all the new stuff released at WWDC it’s been quite a year for app entrepreneurs. And we probably have one more event later this year for the traditional iPad refresh before the holiday season. I wish Apple would take a breather now and just focus on execution and fixing the cracks in the existing tools and infrastructure before unleashing another avalanche of new cool stuff. But I doubt that will happen.

written by Nick \\ tags: Apple Pay, Apple Watch, iPhone 6