Posts tagged with "developers"

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.

Quick Review: RankIt Checks On iOS & Mac App Store Charts

Developed by Steve Reynolds (Analytix, Clicky Touch), RankIt is a new iPhone app that allows you to check on iOS and Mac App Store charts for any app that’s currently available for sale. Whilst some iPhone apps have tried to bring the complexity of web-based App Store analytic tools to iOS in the past, RankIt focuses on simplicity in that it allows you to quickly enter as many apps to “monitor” as you want, and refresh at any time to see real-time rankings.

As you fire up RankIt for the first time, you’re asked to add an app from the App Store you’d like to check rankings for. You can choose between iPhone, iPad, Universal and Mac apps, and change from United States to 9 other markets with available charts. In Settings.app, you can further tweak RankIt to adjust the number of maximum ranks returned (from 50 up to 400), set a default country, and refresh on launch. Once you’ve entered an app to monitor, RankIt will quickly refresh its ranking to check on freshly updated charts. RankIt will display an app’s position in the Top Paid/Free charts, as well as its ranking in the category’s charts. Universal apps will show iPhone and iPad icons next to them; with one tap, you can open a single app view that displays rankings in multiple countries. You can refresh at any time, with RankIt taking only a few seconds to get updated charts from the App Store.

In spite of its simplicity, I believe RankIt can be a worthy addition to any iOS or Mac developer’s workflow. In fact, the app’s focus on “quick stats” might just be its biggest selling point when compared to more in-depth tools that can’t just be refreshed every 10 minutes, whereas RankIt seems to be meant exactly for this – quickly checking on the App Store’s charts. I’ll make sure to test RankIt again during one of the big app launches next week, and see how it handles updates in real-life usage scenarios.

RankIt is $1.99 on the App Store.

The State Of iCloud-enabled Apps

Three months after the public launch of iCloud, I thought it’d be interesting to check upon the App Store and see how many developers have decided to enable iCloud integration for documents & data storage in their apps.

iCloud went live alongside iOS 5 and OS X 10.7.2 on October 12th, two days ahead of the iPhone 4S’ launch. In retrospect, iCloud’s public debut wasn’t without its issues and hiccups, but it was relatively smooth in the following days and Apple acted promptly to restore interrupted services for its users. Looking back, it’s just weird how many times iCloud Mail has been down, and continues to be unstable, whereas iCloud sync (for apps and data) has been fairly responsive and, at least on my side, always up. This says a lot about priorities, I guess.

In 107 days since iCloud went live, and 235 since Apple’s announcement at WWDC ‘11, it appears the majority of third-party developers are still considering whether or not iCloud is something worth investing their time – and customers’ money – or not. Those who have successfully implemented iCloud have done so in ways that require minimal user interaction, most of the times enabling sync capabilities through a single setting switch. Others have tried more complex solutions, often having to come up with separate tools to enable iCloud. Especially on the Mac, the fact that only apps sold through the Mac App Store can be directly integrated with iCloud isn’t helping developers who are still selling apps both on Apple’s App Store and their own website. Overall, there seems to be a shared trend among developers choosing to wait for Apple to clarify specific aspects of iCloud sync, improve the platform and fix some bugs that may prevent certain applications from being iCloud-enabled without requiring a major restructuring of the codebase on their end. Turning an iOS or Mac app into an iCloud-enabled app hasn’t turned out to be the 1-click process many, including me, wrongfully assumed when iCloud was previewed at WWDC last year.

Every app has its own way of storing local documents and user data. Some apps prefer keeping the original source of a document intact, say a .txt file, whilst others may apply their own file format to store documents and data internally in a proprietary database or multiple files, such as Evernote’s take on XML. There are pros and cons: keeping a universal file format such as plain text gets you more benefits in data portability; writing your own database structure allows you, as a developer, to do things exactly the way you want. What does this mean for iCloud?

Without getting too technical (also because my knowledge on the subject can only get you so far before I suggest you go read the developer documentation), the developers I’ve talked to explained that in the way iCloud syncs file, there may be some incompatibilities with apps that are based on complex databases and libraries. Apps that simply want to sync .txt files across multiple devices might be easier to port to iCloud, but then again there are always some aspects to consider such as conflicts, renaming a file, or getting a timestamp for the modification date when multiple devices are accessing iCloud. That’s not to say implementing iCloud is technically impossible for apps that are based on libraries, and not easily exportable files: below, I’ve collected some examples of apps that do just that, and quite cleverly too. However, getting to enable iCloud and make it reliable enough so that all kinds of apps can work with it without frustrating the user (who, in theory, never has access to the inner workings of iCloud) while at the same time providing the functionalities he or she expects. Read more