iPhone app Developers | iPhone and iPad Developers

Author Archive

Author Archive

Drop iOS 5: Only support iOS 6

by in News on Nov. 20, 2012

Many people we talk to are concerned about developing software that targets newly-released or pre-release OSes.  What if most customers are still running iOS 5?  Isn’t it taking on unnecessary risk?

No.  By far the bigger risk is supporting old version of the OS like iOS 5.  For the vast majority of new software development, it’s a critical strategy failure to target old versions of iOS.  For new software projects, you should be targeting the shipping version or even preproduction versions.

Why is this?  Let me sketch it out on my whiteboard for you:

(I hope you will forgive me for not including many units in my rough sketches.  When I show this to clients, I’m usually talking about their specific project and using actual projections.  It’s pretty hard to come up with numbers that are accurate for every reader of this blog!)

Let’s take a look at your typical adoption curve.  What most people want to know is, “How many customers do I reach if I target iOS 6?”  And you will get various answers depending on when the figure was reported: within 48 hours of its release, adoption was 25-35%.  30 days following its release, it was about 60%.  Our own figures indicate that today adoption is in the 70-80% range.

But the dirty secret is that your app isn’t going to be released today–it’s going to be released (at least) several months from now, when the adoption statistics are even higher.  Perhaps the development time for a “typical” app is 90 days, and during those 90 days, an OS can go from 0% to 70% marketshare.  So there is literally nothing useful marketshare numbers will tell you that will still be accurate when your application is released.

Even worse, supporting older OSes takes additional time, which contributes to your ship date.  It is impossible to quantify exactly the cost of targeting older OSes, as for some applications it may present itself as test and debugging overhead, whereas for others it may present as months spent backporting new Apple technologies to previous devices.  Still in others, it may present as simply not having certain new features, like Passkit, not supporting the new 4″ screen of the iPhone 5, and so on.  However, let’s suppose you are doing something “average” and call it an additional 20% time to support iOS 5:

First, we see that adoption statistics are worse than useless, because the needle will move quite a bit over the course of development.  Second, we see that even as we have spent additional time trying to capture iOS 5 users, those users have continued to migrate to iOS 6.  Just doing nothing would have captured that marketshare.  The number of actual customers that we capture with an iOS 5 strategy is extremely small:

Just think: we have gone to all this time and effort, and extended our development schedule by 20 days, just to capture this very tiny sliver of the market.  Just for reference, contrast this with the size of the iOS 6 marketshare that we get “for free”:

So what you see here is that the Cost-To-Acquire (CTA) an iOS 5 customer is vastly, vastly more expensive than acquiring an iOS 6 customer.  It is 10x or 100x the cost per customer.  For the vast majority of applications, the cost to acquire iOS 5 users exceeds the licensing fees they would pay by a high multiplier.  (One of our client discovered that it was cheaper to buy a new device and mail it to each obsolete user than it was to continue supporting iOS 5!)  This is even before considering questions like how, if they are seemingly unaware of the software released by Apple, a multibillion dollar corporation, customers are going to hear about your software.  Or how, if they cannot afford to upgrade a 2-year-old device, they are going to afford your software.

Let’s look at our growth trajectory with two different release dates.  Obviously the trajectory for every application is different–some are linear, some have viral growth, many fail to sell at all.  Some enterprise applications have a fixed customer base. Still other software has a subscription model.  But the value of many kinds of applications (whether in licensing fees, in subscriptions, in business value, etc.) can be modeled with linear growth, so let’s take a look at linear growth after our app’s release:


We could have released our application for iOS 6 only after 90 days, and we would have achieved the growth shaded in green.  Alternately, we could have released our application for iOS 5 and 6 after 110 days, and we would have achieved the growth in red.  The difference between them is our revenue gap, and it is very, very difficult to close.  If conditions are ideal for a very long period of time, the right application may be able to close the gap.  But due to competitive and seasonal reasons there is no such thing as ideal conditions for long periods of time, so the gap is, for all practical purposes, uncloseable.    Not only has our iOS 5+6 app been more costly to produce; but it has also led to decreased revenue at any particular point in time due to a delayed launch.

But even that’s not the full story: the choice is not between the development team working 110 days vs just working for the first 90.  We have to consider the opportunity cost: what the development team could have done instead during those 20 days.  For example, they could have quickly shipped an update adding new functionality, or they could have watched customers use the application and released a quick update making the core app experience better and driving revenues even further.  Let’s take a look at what happens if our development team directs their energy into new features to attract even more customers:

If our revenue gap was uncloseable before, it’s definitely uncloseable now.  What started out as a perfectly innocuous question: “Should we target iOS 5 or iOS 6?” turns out to have implications that will probably save or sink your project.

Unfortunately, many people in charge of mobile projects are still stuck in a pre-iOS mindset where customers are always years behind.  This has been the reality in the desktop world, in the browser world, in the embedded world, and so on for many decades.  It is even still true on some mobile platforms, like Android.

But as we’ve seen, it’s quite dangerously wrong for iOS development.  This is one of the many reasons why, if iOS is an important component of your mobile strategy, it is vitally important to have a mobile strategist who truly understands iOS.  Your competitors have.

If you need a strategist to help you make sense of the iOS market, look no further!  Contact us today and get actionable insight to bring your products to market faster and more effectively.

A peek inside Caffeine

by in Uncategorized on Nov. 16, 2012

We work on a lot of varied projects here at DrewCrawfordApps, and our wide view lets us see common problems in software development that help to raise the tides of all ships.

One problem that we’ve identified is the terribly sad state of client/server software development on iOS.  Many applications require access to business data stored in the cloud, and this data is stored in a form designed for big, beefy servers and power-hungry desktop applications to interact with, not five-watt mobile devices on spotty cellular connections.  The result is slow applications, frustrated users, and a continuous upgrade cycle that always promises improvement, but never delivers.

The problem is that an entire alphabet soup of technologies: HTTP, SOAP, XML, REST, SSL, SQL, and many others–were all designed for the desktop world, or even perhaps for the mainframe world.  It is tempting to use the alphabet soup, because it already exists and is well-understood.  But it also requires a great deal of tuning and customization to eek out mobile performance, and the end result is still mediocre.

From our vast experience working on client/server applications, we’ve re-thought the entire alphabet soup, and have developed a new client/server application framework, called Caffeine, that is built from the ground up for mobile applications.

Built for speed

Let’s start with a benchmark: Here’s the time spent processing a fairly ordinary network request with our new Caffeine technology and without it:

As you can see, Caffeine takes only 12% of the time to serve a request as with other current-generation technology.  This result is before any caching or compression advantage: an exact apples-to-apples comparison between our Caffeine technology and the way most people write iOS client/server applications now.

How do we achieve a result like this?  To answer that question, let’s look inside a typical request:

As you can see, the bulk of each request is spent in the SSL layer, but there are many other contributors to the problem. What we’ve done is take a look at each of these layers and trim the fat, resulting in new tools that get the job done much faster.

SSL: A symptom of the problem

SSL is one of the major villains of this story.  Originally a proprietary encryption scheme created by Netscape, SSL has grown into a complex negotiating protocol involving thousands of pages of specifications that are implemented, rather poorly, on a dizzying number of platforms.  The result is that after a long and tedious negotiation process that takes about a second even on fast desktop systems, both client and server eventually settle on poor and insecure encryption algorithms because that’s the only thing that’s supported on both systems.

Worse still, the dizzying array of libraries and their confusing settings cause many developers to misunderstand how to use them, leaving many applications critically vulnerable to attack.  Researchers from Stanford and the University of Texas recently declared SSL libraries “the most dangerous code in the world” and concluded:

We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries. Vulnerable software includes Amazon’s EC2 Java library and all cloud clients based on it; Amazon’s and PayPal’s merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware—including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android—and all applica- tions employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack. The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present developers with a confusing array of settings and options.

In contrast, we’ve built Caffeine’s security around the latest work from world-class cryptographers, have designed it in a way that is on-by-default and without anything to configure, have eliminated obsolete protocols that many SSL users still rely on for historical reasons, have cut the number of network round-trips by a factor of ten, and have cut the data transfer required by a ratio of 30:1.  The result is a fast, simple, secure protocol that makes your application significantly more performant, and requires only 48 bytes of overhead for many gigabytes of data transfer.

And then we’ve replicated this kind of ruthless examination to every single factor that contributes to request time in order to squeeze out maximum performance.  We’ve replaced XML and JSON with a more efficient binary protocol that is more easily parsed on the multicore machines of tomorrow.  We’ve adopted a special TCP variant that is used by the high-frequency traders to execute light-speed transactions on Wall Street.  We’ve pushed technologies like caching far beyond where they have ever been before.

Built for iterating

We’re a small shop, and it’s important for us to have technologies that let us get new features out the door quickly.  Adding new features to enterprise applications often involve a whole team of experts–the DBA, the server team, the client team, operations, IT, and many other roles.  Our goal with Caffeine was to eliminate the day-long planning meetings and get new features live in just a few minutes.

One of the biggest timesinks in client-server development is writing and documenting all the boilerplate–getting a small amount of data our of the database, through the server infrastructure, and into a client application for your users often requires an entire team of experts and complex data conversions.  It takes a long time to produce this information, and a longer time to implement it, and longer still to realize that there is a problem with it and that it needs to be changed, and this translates into software delays as meetings are scheduled and re-scheduled to implement features that are a constantly moving target.

Caffeine lets a server developer simply say “Anyone can call this function”–and that’s it!  It automatically generates iOS source code to call the function and perform any necessary conversions, parse results, and perform database queries.  It even does very hairy conversions–like converting dates and times between their “preferred” representations on each platform–or you can even send custom classes back and forth over the network to do your own business logic, which are automatically generated in a multiplatform way.

But that’s not all–client developers can design their own APIs!  The big elephant in the room for iOS applications is that often the server returns results in the wrong order, or in the wrong chunk size for maximum performance, and the server developer is often in the wrong position to judge the network constraints of a mobile client with variable bandwidth.  This leads to slow applications and frequent API changes.

Instead, Caffeine exposes a powerful query language to the client developer, so that clients can decide things like batching size, sort ordering, joins, and filters.  This is expressed in an idiomatic CoreData query on iOS that is familiar to mobile developers–but is compiled into SQL queries that make sense to server developers and DBAs.  This is all combined with aggressive performance tuning that prunes unneeded data from requests and loads data lazily ensuring that even the most complex queries run at maximum performance.

A new kind of software development

The marriage of these two ideas–performance and development speed–lead to new kinds of practices and new possibilities for mobile software.  When network requests become faster, cheaper, and easier by factors of 10 and 100, it changes the way mobile software is written.

For example, most mobile software today relies very heavily on caching to achieve acceptable performance.  But caching introduces its own problems: caches go stale and become out-of-date, inconsistencies in the dataset are introduced that are hard to detect, and other subtle bugs are expensive to fix.

We’ve noticed that Caffeine-based applications are so fast that they actually eliminate most of the need for caching in the first place.  Remarkably, they even have less persistent state than local applications, because it is easier to pull data in again from the network than it is to figure out where to store it locally, and the performance is so good that usually nobody notices the difference!

We believe that it isn’t enough just to take the desktop experience and put it on a tablet or a phone; that the software of tomorrow needs to not just to be a “mobile” or “lite” version of your site or product, and not even just to do what its counterpart desktop software did.  But to do more, and do it faster and better.  Your iOS software should be the best experience for your product or service, not just on parity with the other platforms or a “watered-down” experience.

Caffeine is just one of the many tools and technologies we use here to build the software of tomorrow, and to build new kinds of products that were not possible before that push the boundaries of what client/server software can do.  If you think your mobile application could benefit from Caffeine’s performance or your team could benefit from reduced client/server development time, or if you’d like us to apply this same methodical approach to your software, get in touch with us today to talk specifics.  Caffeine is the only technology of its kind, and licensing and support to accelerate your product are only available from us.

With 9% marketshare, Apple has 75% of all cell phone profits

by in News on Feb. 5, 2012

According to CNN, Apple’s “tiny” 9% marketshare accounts for 75% of all cell phone profits.

This chart covers all phone sales, not just smartphones, and the whole world, not just the U.S.  This teaches a powerful lesson: more marketshare does not mean more money.  Not all customers are created equally.  Android’s marketshare looks impressive, but when you drill down into the details, you discover that one Apple customer can drive as much revenue as 5 or 10 Android customers.

This is just one more reason to focus on iOS as the primary platform for your application.

Don’t support iOS 4

by in News on Jan. 29, 2012

Many clients mistakenly believe that supporting previous versions of iOS software is important.  But almost universally, supporting iOS 4 and earlier is a bad investment.

Most iOS users can upgrade

Unlike other platforms where software updates are provided for very limited windows, Apple’s updates run on devices up to two years old.

Apple works hard to make new versions of iOS available to an unprecedented number of users, even those users who may be running older devices.  The vast majority of your potential customers don’t need new hardware to run iOS 5.

Most iOS users have already upgraded

Within 5 days of launch, iOS 5 was in use by 33% of devices.  Marco reported in November that 48% of his customers were running iOS 5.  Bump reports that iOS 5 penetration is about 60%, (with the next-oldest OS, 4.3.3, being a paltry 9%).  Our internal statistics show that our customers are close to 70%-80% iOS 5 users.

And don’t underestimate the length of your development cycle.  New applications often take 90+ days to develop, and by the time your application actually ships, the numbers will be even higher.

Supporting iOS 4 is expensive

Supporting iOS 4 means double the test burden, means that everyone has to buy extra devices to test older configurations, and means that the cost to test your software triples.  These are the obvious costs.

Supporting iOS 4 has hidden costs too:  it means that great developer features introduced in the last 6 months can’t be used in your application.  This increases development time and cost significantly, as complex “workarounds” have to be created to avoid the use of these features.  These design choices can have long-lasting permanent effects on your software’s code base that will far outlive iOS 4.

But there’s another hidden cost:  supporting iOS 4 means using fewer iOS 5-specific features.  Apple users expect a high-value experience on their shiny new Apple device, and if your application fails to deliver the latest and greatest, you’ll get bad reviews.  If you have a competitor who produces a more highly-featured application, expect a large portion of your customer base to pass over your app in favor of the competing one with iCloud support and Notification Center integration, Twitter integration, and other iOS 5-only capabilities.

Supporting iOS 4 is bad for business

At this point, most of the iOS 4 holdouts are either people with very old devices (cheapskates unlikely to buy your product), or users who are technically incapable of performing a software update (and who will present a high technical support burden).  These are not the kind of customers you want to be burdened with.

Supporting iOS 4 can be attractive in a requirements list, but it can be a costly exercise that provides no real revenue to justify its cost.  Many developers make good money supporting iOS 4 at a markup, but in the best interests of our clients, we recommend that the vast majority of new applications be written to support a minimum of iOS 5, and that significant (non-bugfix) updates to existing apps seriously consider dropping support for older versions of the OS.  Focusing on iOS 5 provides the best value for most projects, and redirecting legacy costs into new feature development can be much more exciting for both you and your customers.


Apple vs Android in the enterprise: Not even close

by in News on Jan. 29, 2012

Android has been making some gains lately in overall marketshare.  But AppleInsider has some fantastic charts today showing off the widening gap between Apple and Android in the enterprise:

It’s not even a fair fight.  Even the least-owned iOS device, the iPhone 3GS, beats the pants off the most popular Android device.  If you’re targeting enterprise users or business users and you’re developing an Android version, you’re throwing money away.

Things get even worse for Android when you consider operating system fragmentation.  Here’s the same chart that overlays the latest supported operating system for each device:

Writing a universal iOS application targeting iOS 5.0.1 is hands-down the best value in the mobile development world.  Targeting the single iOS 5.0.1 version gives you access to the vast majority of customers.  Targeting Android means targeting many different versions of the Android OS to gain only a tiny amount of additional marketshare.

Here’s a combined chart:

Notice anything strage?  Android Tablets in business are competitive with Bigfoot sightings.  If you are developing business software for an Android tablet, you need to stop immediately.  You’re better off just shredding your money.

This person is making a better investment than developing an Android tablet application

The agility of small teams

by in News on Nov. 17, 2011

Some managers think that it’s important to have lots of programmers working on a project.  After all, the more people you have, the faster it will get done!  But nine pregnant women can’t make a baby in a month.

Adding more people to a late software project makes it later.  - Fred Brooks

In fact, large software teams lead to project stagnation.  Doug Putnam published research from 491 software projects.  His research demonstrates that as a team gets smaller, its overall productivity increases:


And the effort to deliver a software project rises exponentially with the size of the development team:

This seems to be a very nonintuitive result.  How can it be that adding more people to a project makes it worse?

The answer is that software development requires tight communication between all members of the team.  A team of 2 requires only a single communication channel.  But for a team of 7 people, 21 different communication channels are required.  Each member of the team must sync with each other member so that everyone stays on the same page.  As new developers are brought on board, they must be caught up to speed by existing developers who are taking time away from new work to educate others.  Pretty soon, everyone is in meetings, writing documentation, managing wikis, sending e-mails, and trying to communicate with everyone else instead of moving the project forward.  It is not uncommon for members of large teams to spend 80-90% of their time on communicative tasks.  As a result, progress stagnates, and the schedule slips.

A team of just 2 or 3 developers, on the other hand, is a productive team.  With only a few communication channels, each member can spend most of his or her time working on the project instead of answering the questions of other team members.  Meetings can be reduced to just an hour or two per week, and extensive documentation can be replaced with lightweight communication tools.  Small teams appear less impressive, but they ultimately get more done.

At DrewCrawfordApps we deploy small teams on our development projects to deliver quality software quickly and reliably at a pace that outstrips large teams with dozens of developers.  The next time you are thinking about using a large team for a project, consider whether that team will be as productive as a lightweight and agile team without the additional communication overhead.

Agile iPhone Development

by in News on Nov. 15, 2011

At DrewCrawfordApps, we practice an agile development methodology based on multiple small sprints and continuous delivery.  This is because agile methods provide higher productivity, lower costs, result in higher quality software, and happier clients.

Higher Productivity and Lower Costs

According to VersionOne’s 2010 study, 66% of agile practitioners report faster time-to-completion for software projects.  More than half of all respondants report that agile has “Significantly Improved” or “Improved” their ability to respond to change, alignment with business objectives,   team morale, time-to-market, productivity, software quality, risk management, engineering disciple, and software maintainability.

But a significant feature of Agile is that developers are less likely to build software that is no longer needed.  When software development iterations are large or are done in a “big bang” fashion, the long lead times between specification and delivery can mean that the features requested are no longer relevant to users.  Shortening the feedback cycle means that engineering resources are spent on delivering features that are actually useful, instead of out-of-date by the time that they are delivered.

VersionOne found that 74% of those surveyed reported that morale was improved through the introduction of agile processes.  Improvement in developer morale not only means higher-quality productivity as developers are motivated to work harder to ship software, but also that the highly mobile top tier of technical talent can be more easily acquired by the organization.

Faster to Market

Rally Software’s in-depth study of agile development showed that Agile practices lead to a 37% faster time-to-market for software projects vs traditional methods.

Salesforce.com reports a +568% increase in features delivered to customers as a direct result of implementing agile methods.



Higher Quality

David Rico’s research on Agile development showed that Agile projects have a median quality improvement of 63% over traditional methods and a minimum quality improvement of 10% in the companies he surveyed.  84% of the VersionOne survey respondants felt that Agile methodologies had reduced the number of bugs by 10% or more.

Improved Client Satisfaction

With all of these improvements, it’s no wonder that these practices lead to higher satisfaction among iPhone project clients.  iPhone development is a fast-changing world that moves even more quickly than other types of web, desktop, or systems development.

Many potential clients make the common mistake of adapting a traditional software development process to the mobile development world, without a true understanding of the assumptions and underlying requirements of the development methodology.

The iOS software market is much  more competitive than the traditional software market, because there is only one primary sales channel–the Apple App Store.  As a result, millions of software products compete for the same real estate.  Even in a “niche” vertical, there are often many software vendors competing for customer dollars.  If a competitor is using a lower-cost development methodology, that competitor will be able to consistently deliver a higher-quality experience to its users, putting you out of business.

Even if you have no competitors, Apple itself dictates a rapid pace for the iPhone and iPad application market.  iOS, the iPhone and iPad operating system, is currently on a yearly release cycle.  Because of Apple’s highly secretive product roadmap, it is very difficult to predict the future in this market.  Apple’s rapid improvements to iOS can obsolete dozens of product lines from individual developers overnight.  Sudden announcements can cause an unforseen shift in development, due to added or removed functionality in the underlying operating system or new hardware capabilities.  In this challenging marketplace, it is more important than ever to adopt an agile software development process for your iPhone projects, both to stay current on the latest Apple development practices and to remain competitive in a marketplace of other agressive software developers.

It should come as no surprise that according to a study at Colorado University, an overwhelming 80% of respondents reported an increase in customer satisfaction after introducing Agile methods.  Agile development methodologies are an important ingredient in our overall strategy at DrewCrawfordApps to deliver the highest quality software at the fastest possible speed.  When selecting a development partner for your iPhone project, make sure you are working with a development team with an understanding of the unique challenges of the iOS marketplace and with a development strategy that will lead to success for your iPhone development project.

iOS Developers are in Demand

by in News on Nov. 10, 2011

MacWorld has published an article discussing how difficult it is to hire qualified iOS developers:

“We’re 100 people, but we have work for 130 people. We just don’t have those extra 30 bodies,” Michaels says. He adds that salaries for experienced iPhone developers “just keep going up. Our year-over-year salaries are up almost 20 percent.”

iOS development is a demand market right now. There simply aren’t enough qualified developers to meet the enormous business demand. Due to the high technical nature of iPhone and iPad development work, this is a situation unlikely to improve in the near future.

The high market demand is pushing unqualified and marginally-qualified developers into the market, who are unable to deliver on business objectives. This is why horror stories of bad hires and bad contractors on the iOS market keep getting published. TapTapTap, a market leader in iOS publishing, writes about their bad contractor experience:

We continued to sink a lot more money into the project, partly because we wanted to add some cool features that we came up with, but mainly because Daniel couldn’t deliver anything even close to being worthy of shipping. And even though we weren’t supposed to pay until completion of the project, we did so on good faith, mainly because of Daniel’s never ending sob-stories. literally months would go by without an ounce of work being done on the app. When he did actually come around to doing some work on it, subsequent builds improved slightly, but we never got the the point where someone would ask us about plasma and we’d be proud to show it to them… instead it was usually quite the opposite and more of an embarrassment for us.

MacWorld has this to say about overseas outsourcing:

“This is not a skill that goes well with outsourcing because the typical shops in India and the Ukraine are focused on wider-breadth technologies such as Windows, and there aren’t a lot of Mac developers there,” Michaels explained. “Most of the Mac developers have always been around Cupertino and San Francisco, where Apple is located, and there are some in Seattle, Portland and Vancouver.”

When you are looking for an iPhone or iPad developer for your project, make sure that you do the technical due diligence to hire a candidate with a track record of timely delivery of iOS projects that operate well, are written with best practices in software engineering, and meet technical and functional requirements. Your project is too important to leave to chance.

iPhone 4S announced

by in News on Oct. 5, 2011

Apple announced today the release of the iPhone 4GS.

Some of the major improvements, from an app developer point of view:

  • The new A5 chip will give mobile developers new opportunities for complex calculations. More than just the gaming examples Apple demonstrated in the keynote, productivity and business applications can also reap large benefits from the new chip.
  • The new camera and photography software will place an increased focus on video and photography applications. We see photography and videography apps as a major growth area on iOS.
  • Although Siri is still in beta, at the moment we are not aware of any opportunities for third-party developers to integrate with Siri and allow voice control of their applications.
  • AirPlay Mirroring, introduced on the iPad 2, makes it easier to display iOS apps in presentations.

The iPhone 4S is largely an incremental improvement over its predecessor rather than a complete redesign. It has many new and exciting features, but at this point it does not represent as large of a shift in iOS app development as iOS 5.

iOS 5 announced for October 12th.

by in News on Oct. 5, 2011

Apple announced the public release of iOS5 on October 12th today.

We have been testing iOS5 for several months now, and we are very excited about many of the new features:

  • Twitter Integration & Game Center improvements – Integrated properly, this can make apps more discoverable which translates directly into improved app rankings and sales
  • Newsstand – this is an important new feature for magazine and subscription applications. We expect to see many print publishers produce apps incorporating these features.
  • Notification Center – this will make notifications more useful in general. Since many applications send push notifications, this will make notifications less intrusive to users and will make it more likely for users to subscribe to push notifications knowing that they will be less invasive.
  • iCloud – we believe the ease of integrating iCloud and cloud syncing will reduce the technical bar to creating applications that share user content across multiple devices. With many users purchasing second and third iOS devices, data synchronization is more important than ever.
  • Automatic Reference Counting – while it’s not a user-visible feature, this important new technology helps reduce the cost and effort of writing iOS applications. We are working hard to get ARC technology baked into new applications and future updates.