Posts tagged with "developers"

The (Big) Numbers Of The App Store Platform

Today’s news that Paper, a sketching app for iPad, has been downloaded over 1.5 million times in two weeks made me think about the size of the App Store platform and ecosystem of devices. Launched in 2008, the App Store now extends across the iPhone, iPad, and Mac, and distributes over half a million apps to customers (588964 apps per AppShopper). Last month, Apple reached the impressive milestone of 25 billion apps downloaded from the App Store – an important number that tops a history of exponential growth and adoption.

Below, I have compiled a list of noteworthy milestones reached by App Store developers in order to put Paper’s numbers in better perspective. For more App Store-related numbers, check out Wikipedia’s milestones table and our Mac App Store: Year One overview.

On January 24th, 2012, Apple announced the company paid over $4 billion to developers since the App Store’s launch in 2008. Over 315 million iOS devices have been sold to date; with these numbers, an average of 79 apps has been downloaded for every iOS device.

App Downloads: A History of Numbers

2009

July: Dictionary.com reaches 2.3 million iPhone app downloads.

2010

March: Doodle Jump for iPhone sells 3 million copies since launch.

June: Skype announces 5 million iPhone app downloads in four days.

June: Angry Birds for iPhone has been downloaded over 5 million times since its launch on December 2009.

September: Gameloft announces 20 million paid app downloads of its iOS games since the App Store’s launch.

2011

January: Pixelmator grosses $1 million in under 20 days.

January: Autodesk announces Sketchbook Pro for the Mac App Store has sold twice as many copies as the regular app in a year.

February: Fruit Ninja for iPhone hits 6 million paid downloads in 10 months.

May: Talking Tom 2 hits 1 million downloads in a single day.

June: Game publisher Chillingo announces 140 million downloads for its iOS apps since the App Store’s launch in 2008.

June: Gameloft announces 200 million iOS app downloads in 3 years.

October: Autodesk announces 3 million downloads of AutoCAD WS for iOS and Android.

October: Discovr announces 1 million downloads.

December: Flipboard for iPhone gets 1 million downloads in its first week.

2012

January: World of Goo downloaded over 1 million times by App Store and Mac App Store customers in 13 months.

February: Scribblenaut Remix sells 1 million copies since its launch in October 2011.

March: Camera+ sells 7 million copies in 1.5 years on the App Store (previously: 6 million copies in January 2012; 3 million copies in June 2011)

March: Angry Birds Space reports 10 million downloads in 10 days (the app is available on multiple platforms and devices, including iPhone, iPad, and Mac).

March: iPhoto for iOS downloaded by over 1 million unique users in under 10 days.

April: Draw Something hits 50 million downloads in under 2 months.

April: Paper for iPad is downloaded 1.5 million times in two weeks.

April: MLB.com At Bat 12 reports 3 million downloads. The app was released at the end of February 2012 on multiple platforms (including Android) and its developers also reported over 800,000 live streams per day.

Apple Seeds OS X Lion 10.7.4 to Developers

Following the release of the second Developer Preview of Mountain Lion earlier today, Apple has also released a pre-release version of OS X Lion 10.7.4 to developers. Build 11E27 is available now for download in the Mac Dev Center to registered Mac developers. A Server build for 10.7.4 has also been seeded to developers.

The last public version of OS X Lion, 10.7.3, was released on February 1st, adding bug fixes and addressing compatibility issues with Windows file sharing. A “supplemental update” to 10.7.3 was released on March 5th to resolve an issue with Time Machine backups.

Apple Releases OS X Mountain Lion Developer Preview 2

Apple just released the second developer preview of the next major version of OS X – Mountain Lion. The new developer preview is available in the Mac Dev Center to registered Mac developers, and it carries build number 12A154q. As with the first developer preview, the build can be downloaded from the Mac App Store with a redemption code. The Next Web has a list of known issues with the latest build of 10.8.

Mountain Lion, officially announced on February 16th, will be released this summer, featuring a number of new functionalities, including standalone Notes and Reminders app, Notification Center, Gatekeeper, and more. Check out our Mountain Lion overview for a roundup of all the new features.

 

Getting Your iPad App Ready for the new iPad

Editor’s Note: This is a guest post by Ken Yarmosh, the creator of the popular iOS apps Agenda Calendar and Buzz Contacts. Read more about him at his blog and follow him on Twitter.

With the announcement of “the new iPad,” developers are quickly readying their apps for the latest and greatest iOS device from Apple. Preparing an iOS app for a more powerful, Retina display device is a familiar task for those developers who got apps ready for the iPhone 4. Whether you do or don’t have that experience, it’s still helpful to have a checklist of sorts for preparing your app for the new iPad.

Here’s that list.

Download the Latest Version of Xcode

Before you get too excited, open up the Mac App Store to download Xcode 4.3.1. This will provide you with the “iPad (Retina)” simulator and the ability to build against the iOS 5.1 SDK. Even though an iOS 5.0.x iPad app will run on the new iPad (or any iPad running iOS 5.1), remember that the new iPad will ship with iOS 5.1. So, building against the proper SDK is always a smart choice.

Update Designs Assets for Retina display

Getting your UI assets updated for the new iPad’s Retina display should be relatively straightforward. Hopefully, you’ve built your application in a way that will mostly make it a design-related task of scaling up your images and applying the “@2x” designation to them. This can be slightly more involved than what was required for the iPhone 4 Retina display update because of the importance of both portrait and landscape on the iPad. Don’t forget to update your “Launch Images” for both orientations, as well as your “App Icons.” If you want more specifics on this topic, see the Apple-related documentation or read Marc Edwards’ post on designing for Retina display on the Bjango site.

Test in iPad (Retina) iOS Simulator

If you want your iPad app looking shiny the day the new iPad arrives, you’ll be stuck trying to use the ginormous iPad (Retina) simulator since the new iPad isn’t available now. Even on Apple’s 27-inch Thunderbolt or Apple Cinema Display, you’ll be struggling to view your app in portrait and barely be able to see it in landscape. Use the window scale and adjust it to 75% or 50% accordingly.

Check Wi-Fi Download Limit

Paul Haddad of Tapbots reported Tweetbot for iPad going from 8.8MB to 24.6MB post-Retina display upsizing. Since many iPad apps are content-intensive, definitely keep tabs on the total size of your app. Even with the new 50MB Wi-Fi download limit, Retina display assets will add up quickly.

Consider New Features

Should you be readying your app for the new iPad on launch day, you’re probably not going to add many new features to your app. But the new iPad does come with more than just Retina display, including the much faster A5X processor, a new camera, dictation (which is available to third-party apps), LTE, and Bluetooth 4.0. Think about how these new features can impact your app and consider how your app might be made better by specifically using them.

Submit to Apple

Apple is now asking developers to submit apps updated for iOS 5.1, including apps optimized for the new iPad. So, once you’ve gone through the steps above, submit to Apple and hurry up and wait. Make sure you mention in your “What’s New” release notes, as well as your version-specific App Store description that your app is now iOS 5.1 tested and Retina display ready. You’re not done yet though!

On-Device Testing

When you get that new iPad in your hands, the first thing you should do is open up your app. Do some pixel nitpicking and ensure everything is working as expected. Faster devices may cause certain parts of the user interface to load faster than others, can handle content pulled in from APIs to process differently, and more generally, may require some small tweaking.

iPad hero

iPad hero

Re-Submit to Apple

If you found issues during the on-device testing, prepare another update and once again, submit your iPad app to Apple. If any crashing or critical bugs were identified during on-device testing, consider (very carefully) requesting an expedited review.

Congratulations, you’re ready for the new iPad. Here’s to 25 billion more app downloads and many five star App Store reviews.

Apple to Developers: Update Your Apps for iOS 5.1

Following the release of iOS 5.1 earlier today, Apple has updated its developer portal with a new “Create Apps for iOS 5.1” webpage, asking developers to start submitting apps written specifically with the iOS 5.1 SDK. The checklist includes links to the iOS 5.1 SDK release notes, Xcode 4.3.1 for developers, and a detailed explanation of the various functionalities introduced in iOS 5.

iOS 5.1, the latest version of the world’s most advanced mobile operating system is now in the hands of millions of iOS customers. Install iOS 5.1 now and download Xcode 4.3.1 with iOS 5.1 SDK from the Mac App Store, so you can test and submit your iOS 5.1 apps today.

Furthermore, Apple has updated the iOS Human Interface Guidelines with new icon size information, as well as the iOS App Programming Guide.

Developers can head over this page to check out Apple’s resources for developing and submitting iOS 5.1 apps.

TestFlight Acquired By Burstly, Launches TestFlight Live

TestFlight, a popular over-the-air testing platform for developers, has been acquired by app monetization service Burstly, the company wrote in a blog post today. Based off Apple’s OTA install technology for beta applications and iOS’ certificate system, TestFlight has been used by thousands of developers in the past year to provide an easy and intuitive way to their users to install beta versions of iPhone and iPad apps without going into the manual process of managing .ipa files with iTunes on a Mac or PC. With a web app that works on desktop computers and mobile devices, TestFlight has powered “over 70,000 developers sharing more than 130,000 apps with a group of 280,000 testers”. The acquisition, explained here, is meant to extend TestFlight’s capabilities as a platform to enable developers to offer beta apps, track revenue and monetization with Burstly, and collect other sets of data and user engagement with a new product launched today, TestFlight Live.

We always planned on launching a production version of TestFlight, but we wanted to push ourselves to start solving production problems and not simply copy the beta feature set. Along with help from the Burstly team, we think we have taken a great first step with TestFlight Live. Our goal with TestFlight Live is to provide a real-time dashboard that displays actions, symbolicated crash reports, and revenue. For the first time, developers will have a single dashboard that provides enough information to derive insights into Revenue Per User (RPU) and Customer Lifetime Value (CLV) to better understand your app business. Previously, this level of information would be from multiple sources and there was no easy way to collect it.

Burstly was the key contributor to the revenue portion of TestFlight Live, in addition to the concept they actually developed the APIs that make it possible. The revenue source options in TestFlight Live enable developers to include app sales data, in-app purchase data, and ad network revenue from multiple partners. You do not need to work with Burstly to pull in any of this data. If you do not want the revenue segment in your dashboard, we have provided a way for you to hide it.

The real-time, mobile-friendly TestFlight Live can be checked out here, and, apparently, developers willing to implement it in their App Store apps will simply have to add one line of code to their existing software to start getting reports from TestFlight Live, which is a free service. TestFlight Live can track things such as crash reports – allowing developers to instantly understand what’s causing an app to crash, thus enabling them to start working on a fix right away – and user engagement in the form of “checkpoints” (milestones that users unlock using an app, such as “launched the Settings screen”), in-app purchases, device types, and OS versions. This system works in real-time, any minute of any day, as long as a TestFlight-enabled app can connect to the Internet. TestFlight Live has a separate dashboard from regular TestFlight, which will continue to be available as a free service to manage over-the-air beta apps.

Burstly integration, on the other hand, opens the door to a bunch of different functionalities, most of them aimed at data gathering in relation to ads and monetization. Burstly can mediate ads from different networks, cross-promote and track installs, provide ads of different shapes and sizes, and offer “criteria” to developers to control what kind of ads are displayed on screen. The service comes with a series of features that are being used by partners such as Rovio, EA, and Zynga. More details are available here.

TestFlight, meanwhile, says that their products and Burstly will remain separate. TestFlight services will remain free, but the developers are looking at paid options for the future. New features on the roadmap (and on track for a March launch) include better performances, a desktop app for developers, and a new UI.

TestFlight, which launched an enhanced SDK back in September, has become one of the most popular options available to developers to manage apps in their testing stages without forcing users to manually install them with a Mac or PC. Another similar service is HockeyApp, which we covered in May of last year (and has improved a lot since). To read more TestFlight’s new owners and the new services, check out the company’s blog post.

Retina & Universal

Matthew Panzarino at The Next Web has a good overview of a possible issue with the rumored iPad 3’s Retina Display and universal apps: download sizes and 3G. He explains:

Apple’s iPad 3 is set to launch next week and all signs point to it having a Retina display running at 2048×1536 pixels. This should provide a clearer, sharper image to most users and will display many applications in a fantastic new light, as long as developers have prepared them properly.

But the necessity to include these images may present a problem with the mandatory 20MB file size limit that Apple has imposed on 3G downloads.

The problem being: if the iPad really goes Retina, then developers of apps using custom graphics will have to use new images, which will likely be heavy and bump the download size of an app. For universal apps, already carrying Retina and non-Retina images (the latter both for iPhone and iPad), this can become a serious issue if we assume that most users who will see the “Over 20 MB” alert will be scared away or simply forget to buy an app. And developers (and Apple) want to make the process of buying apps as frictionless and immediate as possible.

I see two solutions. Either Apple gets the carriers to agree to larger download sizes, establishing a new “average” that should work for most apps (let’s say 60 MB as Panzarino suggests), or they rebuild the download mechanism completely by allowing devices to “ignore” resources they don’t need. The second solution would be a “cleaner” approach, in that it would address the root of this likely scenario – that is, devices downloading apps containing all kinds of images and resources for Retina and non-Retina displays.

By “localizing” images in a way languages are localized on the OS, Apple could find a way to know if an image is destined to an iPad or not. And if so, if it’s also destined to a Retina iPad, or old-generation iPad. Furthermore, in theory, this would also allow Apple to differentiate between images used by an iPhone and iPad which, right now, are always downloaded within the same, single .app package. Paul Haddad, who tweeted about the issue today, confirms my suspicion that this method would require a fundamental change to apps – I can only assume it would require different naming conventions or new APIs to let devices be “smarter” in understanding the resources they need to look for when downloading a new app. But the issue is real – always assuming the iPad 3 will feature a Retina Display, which seems like a pretty good bet at this point – and I think this is something Apple has surely considered.

The other way, of course, is to get carriers on board with larger downloads while on 3G – but the issue of universal apps bumping downloads (and thus 3G usage) would still remain for the users, and Apple would still need to somehow address the core of the issue, which is the existence of Retina and non-Retina devices downloading universal apps containing multiple custom graphics at the same time. I agree with Matthew, this issue will be an interesting one to watch.

Apple Extends Mac App Store Sandboxing Deadline to June 1

With a notice posted on the Mac Dev Center’s App Sandboxing webpage, Apple has informed developers that the sandboxing deadline, previously delayed to March 1, has been extended to June 1.

Starting June 1, all apps submitted to the Mac App Store must implement sandboxing. Take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3.

We have extended the deadline for sandboxing your apps on the Mac App Store from March 1st to June 1st to provide you with enough time to take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3.

Starting June 1, if you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates without sandboxing your app. In addition, if you have technical issues that prevent you from sandboxing your app by June 1, let us know.

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra – utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) – couldn’t get past the sandboxing requirement for the Mac App Store.

Since the release of Lion last summer, Apple has been touting the advantages of sandboxing as a way to increase security on OS X, whilst third-party developers began asking for more clarity from Apple in regards to the list of entitlements made available to them. For instance, sandboxing has been heavily criticized in the past months as it would theoretically prevent apps that rely on system-level technologies such as AppleScript from working, as they would require an entitlement that Apple isn’t providing. Similarly, apps that would require access to an entire user’s filesystem would be problematic with sandboxing fully enforced (think backup utilities such as SuperDuper).

Sandboxing recently became a topic of discussion again as Apple announced the next version of OS X, Mountain Lion, featuring a new security measure called Gatekeeper, while claiming that sandboxing would still be enforced starting March 1. With Gatekeeper and Sandboxing seemingly aimed at fixing different problems with OS X security, a number of third-party developers asked Apple (again) to reconsider the list of entitlements for the sandbox and figure out a way to work with longtime Mac developers to keep their apps in the Mac App Store.

Notably, Daniel Jalkut of Red Sweater Software wrote:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out. Given the current limitations of sandboxing, a significant number of developers will not adopt the technology, so its usefulness to users and to the security of the platform will be diminished. Apple can turn that around so that sandboxing is a worthy counterpart to Gatekeeper, and a technology that any developer in his or her right mind would feel foolish not to incorporate.

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps.

As a result of the uncertainty surrounding the sandboxing deadline prior to today’s announcement, some developers have decided to stop supporting the Mac App Store, keeping their applications available for purchase on their website – something that Mountain Lion will continue to support thanks to Gatekeeper. A notable example is Riverfold’s Manton Reece, who wrote a blog post explaining the reasons behind his decision to remove Clipstart from the Mac App Store:

Clipstart also falls into the same “needs to access the whole file system” category as Transmit. It’s not just one feature; the whole app is based on the fact that it can point to video files anywhere on the system, or manage your video library in a central location on any hard drive. These are things that are difficult to do in the sandbox, but even worse, I don’t see a clear path forward for existing customers to move into such a restrictive environment.

Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.

Following today’s notice sent to developers, Reece told us: “The delay is great news for developers who have been scrambling to meet the deadline. With brand new sandboxing APIs in 10.7.3, it just wasn’t realistic to expect developers to be ready. And for some apps, there are still areas where the current entitlements fall short.” As for Clipstart, Reece says he’s still planning to remove his app from Apple’s storefront: “I still expect to transition away from the Mac App Store. These delays show that Apple is listening, but also that sandboxing isn’t a stable environment yet. I want to focus my time on adding new features for users instead.”

With Apple extending the Sandboxing deadline, the company will hopefully have time to come up with a broader selection of entitlements developers can use in their apps. As a side note, Apple is expected to hold its annual WWDC in June, and Mountain Lion is set to become available this summer on the Mac App Store. Apple seems to be very flexible with the new June 1 deadline, too, promising developers that they will be able to submit bug fixes without implementing sandboxing, and asking them to “get in touch” if technical issues are preventing them from implementing the new technology.

Greed and Entitlements

Nate Boateng has published a very good explanation of why App Store users aren’t entitled to free, universal upgrades of iOS apps:

The thought that a small development team is expected to do months work for free is insane to me. Yes, there are tons of successful apps that are universal (see Instapaper, Due, and Twitteriffic), but the perception that we are entitled to that is not only selfish, it’s just plain wrong. Universal app updates that come for free should be considered a bonus, not a right. A while back Iconfactory developer Craig Hockenberry gave a ballpark on Twitteriffic’s development. He estimated that it cost around $250,000 to develop Twitterrific. Think about that for a second. Still think you’re entitled to free universal updates for the lifetime of an app? I sure don’t.

Today’s Tweetbot releases are just another example of a subset of users that think developers should keep on updating their apps, even adding completely new iPad versions, for free, forever. This kind of controversy seems to take place every time a major iPhone app is released as standalone on the iPad, or vice versa. So I’d like to formulate a quick thought on the subject.

I understand those who say “I would have preferred it to be universal”. Sure, sounds reasonable. I would have preferred my iPhone 4S to come for free in the mail, too, but it didn’t. Stuff isn’t free in this world (even when they give you the illusion of free, you’re the one being sold). What I can’t accept is people getting angry and offensive at third-party developers that decide, you know, to make people pay three bucks for an app that’s been in the works for months. Unfortunately, the App Store doesn’t allow for paid upgrades, so if these people’s rhetoric is that it’s not about the price, it’s about the convenience of a universal binary, well, there isn’t much developers can do about it. Ask Apple.

More importantly, I’m baffled when I see people really getting angry because of a standalone app that was always meant to be that way. So here’s a tip for these people: next time you’re about to send a tweet to a developer, claiming that he promised a free and universal update and he’s now “stealing your money”, do your homework. Because if I can’t argue on economics, I sure think I’m pretty good at Google Search, which brought me to this page (screenshot). From the old Tweetbot FAQ, when the iPhone app was first released in 2011:

Will there be an iPad/Mac version?

It’s a possibility, but we have no plans for it at this time. We are focusing on the iPhone version for now. If we do an iPad version, it will not be universal.

Don’t be greedy. Support indie developers and great software.