Devsugar
Latest
iPhone OS 4.0 SDK Beta 2 available for download
Good news on the iPhone OS 4.0 SDK front. Apple has just posted a brand new beta, ready for you to download. The new beta comes complete with firmware for each of the supported devices (namely the iPhone 3GS, the iPhone 3G, and the 2nd and 3rd generation iPod touch). As usual, the details of this release remain behind the NDA wall, so you'll need to scoot on over and check them out yourself. Apple will be releasing 4.0 into the general iPhone population this summer. An iPad version will debut in the fall. The servers typically get slammed whenever a new SDK is released, so you may want to wait a few hours if you encounter any problems connecting to the developer site. Good luck and happy developing! Update: Minor bug in the OS 4.0 beta 2 firmware discovered. Workaround: Take screen shots via Xcode.
iPhone Dev conference exclusive promo code for TUAW readers
The Pearson Education's Voices That Matter Conference series will be holding their second iPhone Developers Conference on April 24-25 in Seattle. Leading authors and experts (including our very own Erica Sadun) will converge for two days to share their knowledge about developing for the iPhone OS. Development for all iPhone OS devices -- iPhone, iPod touch, and iPad -- will be covered and with the release of the iPhone OS 4 SDK yesterday, you can bet there'll be a lot to learn. Conference registration includes admission to all education and networking sessions, continental breakfast, lunch and breaks, a conference guide, and access to speakers' slides. The price of the conference is normally $695, but Pearson Education has been good enough to offer a $150 discount to TUAW readers. To take advantage of the discount, go to the conference registration page and use the code PHNTUAW. Have a great time and let us know how it goes!
iPod touch devsugar: Fixing ineligible installs
Are you a developer trying to install 4.0 firmware on your 3rd gen iPod touch? You may run into install problems based on device eligibility. That means that Xcode or iTunes will complain that it cannot install the beta firmware onto your device and may tell you that you are attempting an ineligible install. Whether using Xcode or iTunes, your iPod will be left in recovery mode -- and you might think you'll need to restore the device and wait for however many hours you'll need to re-sync all your music, videos and apps back ... Good news: you can kick yourself out of recovery mode and back to your previous firmware install without doing that. Just use a tool like iRecovery. As I discussed in an older post on TUAW, you can use iRecovery to set your iPod to boot back into normal user mode. Download iRecovery from iHackintosh. Run iRecovery from the command line and supply the -s flag. Wait for the "]" prompt, and do not type anything except a carriage return (press return, wait and repeat if nothing happens within 30 seconds) until you see that prompt appear. It helps to only have one iDevice attached to your OS X desktop. Once you have the prompt, enter the following commands: ] setenv auto-boot true ] saveenv ] /exit After exiting iRecovery, you return to the command line. Reboot your phone by pressing the home and sleep buttons for 10 seconds, per the instructions on the iHackintosh, and your iPhone should boot back to its previous firmwall install without re-entering recovery mode.
iPhone OS 4.0 SDK ready for download
And...it's LIVE! The 4.0 SDK for the iPhone OS is now available to developers. Head on over to Apple's iPhone Developer site (login credentials needed) to download the SDK disk image and get started. As with previous beta releases, the new firmware and SDK remains behind an NDA. This NDA will likely remain in place until the 4.0 goes live, which is expected to happen sometime in late spring. The new SDK will support features announced earlier today at the iPhone OS 4.0 roadmap media event.
SDK devsugar: 3.2 leaves beta
As of yesterday, with the release of the iPad hardware, the 3.2 iPhone OS SDK is no longer in beta. The SDK is now available to all members of the iPhone developer program, including the free online program. Normally, during beta, the SDK is limited to paid members only. Since the SDK is now in general release, the NDA will have timed out as well. That means that you will be able to talk freely about the 3.2 SDK outside of Apple's developer forums. Although those forums remain an excellent resource for tracking down information from Apple engineers, they are highly moderated. Since the 3.2 gold master release of the SDK is also known as "Beta 6", you can expect (with a fair degree of confidence) that a new beta should be showing up, behind the NDA and paid developer barricades, in short order. Hopefully, it will address any missing-in-action iPad features and offer some new iPhone-specific features.
iPad devsugar: Moving beyond your 50 promo codes
iPadpalooza is in full swing. If you're like a lot of devs, you're quickly moving through (if not past) your 50 promo code limit per application version. If marketing now is important to you, don't forget that you can gift applications through iTunes. After all is said and done, this will cost you 30% of the price. Apple will return 70% of the cost back to you at the end of the month because you are basically buying from yourself while making sure that Apple gets its cut. Gifting applications offers a reasonably cost effective way to expand your marketing beyond complimentary promo codes. Keep this option in mind as the iPad App Store gold rush gets underway.
Dev Clinic: Submitting Apps for iPad Saturday
<a href="http://www.coveritlive.com/mobile.php/option=com_mobile/task=viewaltcast/altcast_code=f783a9b5f7" >iPad Saturday Clinic: Get your app uploaded</a> Working hard to get your apps uploaded to iTunes Connect? Concerned that there may a world-wide (or at least Apple-wide) conspiracy against you? Come join us for a peer-support but NDA-sensitive discussion about compiling and uploading your application before the Saturday deadline.
iPad devsugar: Application submission clinic tomorrow, 10:30am Eastern time
iPad Saturday is coming -- and is it ever. If you've been having trouble getting your app compiled and submitted to the App Store, then you'll want to join us tomorrow for a special dev clinic. We'll be going over all the basics: how to compile properly and how to submit your app, all while avoiding the Pink Upload Error of Doom. This will be a peer-participation, developer-oriented, NDA-respectful session. So please join us, whether you're looking for solutions or bearing answers. The fun kicks off at 10:30am EDT, 7:30am PDT -- sorry, Left Coast devs, we'll try to schedule another session at a more convenient hour for you if this one is too early. <a href="http://www.coveritlive.com/mobile.php/option=com_mobile/task=viewaltcast/altcast_code=f783a9b5f7" >iPad Saturday Clinic: Get your app uploaded</a>
iPhone devsugar: 9 ways Apple can improve App Store
Apple has been working hard to make the App Store a better experience for both customers and developers. Recently, they introduced in-app purchases, scheduled sale prices for apps, provided review status indicators in iTunes Connect, and introduced other new features. Despite that, they still have a long way to go. Through talking with developers, I've assembled a list of items that Apple might yet look into and implement. They range from issues arising from iPad development and deployment, to longer-standing items that would benefit the entire store. Here, then, is a list of nine suggestions for improving the App Store experience for iPhone OS developers.
Found Footage: Urban Airship's AirMail takes push notifications to the next level
Here's an exclusive TUAW video preview of Urban Airship's latest product, AirMail. Like their other products, AirMail is powered by a precompiled drop-in library that developers add to their iPhone applications. AirMail adds a whole new spin on push notifications by transforming them from lightweight messaging into a more durable and interactive product. Normally push notifications give a simple heads-up to users along the lines of "You have mail" or "Someone tweeted your name." AirMail goes further. It uses the iPhone's push notification infrastructure to enhance two-way communications between service providers and their customers. As this video shows, push notifications are no longer throwaway products. Using AirMail, they can be stored and referenced through an in-app library. Applications can create message histories that persist well beyond the life of a normal push message. What's more, those notifications can involve the user in a multi-directional process, whether confirming that they have taken their pills (as shown here), are ready to take a meeting, or that they acknowledge that a security alarm was triggered in error, among other uses.
Apple is now accepting iPad app submissions
Simulator-only apps developed with the iPhone SDK 3.2 Beta 5 can be submitted as of today for initial review. Upload your apps by 5pm, Saturday, March 27th, and the App review team will e-mail you with submission feedback about the readiness of your application for App Store distribution. You will also receive information about submitting your apps for final review, before the iPad ships and (for most of us) before we even own hardware. If you're thinking about waiting: don't. Apple states that "[o]nly apps submitted for the initial review will be considered for the grand opening of the iPad App Store." An Apple spokesman further confirmed that "[W]e are looking forward to having an amazing line up of apps available when the iPad ships on April 3." The iPad App Store will launch at the same time as the iPad device.
Anticipating WWDC
It's March. It's the month where beer turns green, where the road repair crews start taking over the midwest of the United States, and when Apple usually announces its Worldwide Developers' Conference dates. With the hotly anticipated iPad introduction this year, more devs than ever are looking forward to seeing what WWDC will have on offer. Will WWDC bring the iPhone OS 4.0 announcement and the hardware refresh that we've speculated about? Or will the iPhone OS family remain in the 3.x generation for the foreseeable future? (The current release for the iPhone and iPod touch are at 3.1.3. The iPad will ship with firmware 3.2.) That's the question that has a lot of devs scratching their head. In the past two years, March has been the time when new iPhone SDKs were provided to developers, with the actual firmware released a few months later, somewhat in sync with WWDC. This year, with the iPad release due for the first week of April, the iPhone refresh seems to have been pushed out, or even to the side. Will Apple's WWDC announcement help clarify where we stand in the iPhone lifecycle? That's hard to say. I know a lot of devs are hoping that a new beta SDK will debut sometime in April, once the iPad has been released; with the new version focusing on the iPhone, WWDC sessions would follow up on that build. It would make sense to bring the iPhone up to at least 3.2, so that firmware releases remain in sync across all iPhone OS devices; however, by Jim Dalrymple's estimation we won't see a unified firmware version for both families until the autumn. What about iPhone OS 4.0? With the WWDC keynote being the only remaining scheduled event keynote in the Apple yearly cycle, it would make sense for Apple to use that platform to announce major a iPhone OS update, or a major Mac OS update for that matter. However, the bottom line is this: Apple keeps its secrets. We'll know when they tell us. That can make third-party planning challenging -- whether you want to schedule flights to California for WWDC, or prepare your applications for major firmware updates. We've emailed Apple for clarification on WWDC timing, and have yet to hear back. Here's a quick run-down of past TUAW WWDC announcement posts for your reference. WWDC '09 Details Posted Spring is in the air, although we're in the midst of a blizzard here in the Denver area. That means one thing -- the Apple Worldwide Developer Conference (WWDC) is coming soon!Eric over at... Apple announces WWDC 08 dates With the iPhone SDK announcement last week, some of us here at TUAW were expecting a Worldwide Developer Conference date to be announced. Thankfully, the world has been put to rights, as Apple has... AppleInsider: WWDC to take place June 11th - 15th Take this with a grain of sodium chloride, but AI is reporting that "people familiar with conference planning" have tipped them off to the dates of this year's World Wide Developers Conference.... Also of interest: Apple's WWDC dates announced Rumor: Moscone schedule + "corporate event" = Verizon iPhone?
iPhone devsugar: Unit testing for iPhone view controllers
Unit testing refers to a software validation methodology that allows programmers to test individual program units for correctness. It's been an ongoing question in the iPhone developer community as to whether the iPhone's view controller class is testable or not. In response to these discussions, iPhone developer Jonah Williams has written up a view controller unit testing how-to over at the Carbon Five web blog. His write-up offers examples that show how to incorporate some best practices into your code. Williams points out how broken NIB bindings are a common problem for iPhone OS applications. To address these issues, he regularly adds simple assertions that test that each IB outlet and action are set properly from inside his view controller class implementations. These assertions check that IBOutlet instance variables are not set to nil and that IBAction targets have been assigned, adding a layer of protection against broken bindings. Another typical view controller issue involves responding to application memory warnings. To respond, he adds tests that ensure that each view-dependent property gets correctly released and re-created as views unload and then later reload. By building these into test methods, he can execute this behavior on demand, and ensure that the sequence will execute flawlessly in real world conditions. Finally, Williams discusses view controller interdependencies. Often instances are tightly intertwined, with objects acting as clients for each other. For example, a simple table view controller, living within a navigation controller, might present a detail view via yet another view controller when a row is selected. That's three separate controllers to account for, when you really only want to test one at a time. Williams suggests isolating these view controllers away from their interdependencies to test each component separately and provides examples of how you can do so. What made Williams' approach pop for me is how he carefully exposes and isolates dependencies for testing. These are features that can otherwise be hard to inspect and validate in the normal course of programming. His write-up is well worth reading through, and provides an excellent jumping off point for investigating view controller unit testing.
iPhone devsugar: The need for multiple ipa delivery
App Store clutter remains an ongoing issue. In addition to "business card" applications that offer little or no functionality beyond a simple web page[1], there are lite editions, demo editions, full editions, and even in the case of Tweetie 2, completely new applications providing upgraded functionality. Each of those applications must be registered with a unique app identifier, each one takes up a separate slot when installed on your iPhone's home screen, each application occupies a separate App Store listing, complete with its own screen shots, marketing material, reviews, and so forth. Each one must be managed by you in iTunes, where you must decide which to sync, which to keep, and so forth. Add to the mix, the possibility that we're likely to see iPad- and iPhone-specific application releases in the near future in addition to the Universal Application solution that Apple has been heavily promoting. That's because iPad applications offer developers the opportunity to re-imagine their interfaces, adding features without the constraints of the iPhone's small screen and modal interaction limitations. An iPad app that adds significant new functionality may branch off and become yet another related app in a single application family.
Big Developer News: Mac Dev Program reduced to $99
After a many-hours outage, the Apple developer site is back -- and the changes are profound, at least on the Mac end of things. On the iPhone side, users are required to update their profiles, take a rather obnoxious survey and agree to new terms [Developer credentials required for link]. Unfortunately, Apple needs to improve the default survey formatting. iPhone developer John Fricker points out, "If you go to My Profile you can take the iPhone developer 'survey' with better formatting." But it's on the Mac side where the big news is. Apple has replaced the select and premiere memberships with a single-tiered, low-priced Mac Developer program. They write: We recently introduced a new Mac Developer Program that replaces ADC Premier, Select, and Student Memberships. If you are a current ADC member, you can continue to access your resources and benefits through the end of your membership year.
Should you be building universal apps for App Store?
Universal apps. They're the solution for delivering your iPhone OS application to both the iPhone and the iPad and having it run natively on each without silly make-do's like pixel doubling. It's a way to ensure that your app "fits" each platform, providing art and interfaces that match the target screen. Or, as Apple puts it, "Developers can now start planning for universal applications, allowing them to take full advantage of the technologies found on iPad, iPhone, and iPod touch with a single binary." Right now, I've got a bug up my sleeve about the whole issue. I'm not convinced that it's the right solution for a lot of apps. Just because you *can* merge an iPhone app with an iPad app, and sell one product, you shouldn't -- unless the functionality is significantly the same for both platforms.
iPhone devsugar: Create shiny buttons easily
iPhone developer Jonathan "Schwa" Wight offers a great little trick for creating pixel perfect glassy buttons: using the unofficial UIGlassButton class in the simulator to build your art. In his code paste, he shows how to build a button and render it to a PNG, which you can then save to your desktop. It's a great little trick, and one worth adding to your development arsenal. Be aware that UIGlassButton is a private class, and one that has long since been relegated away from the official SDK development path. Although it continues to work on the Simulator, it's not for use on the iPhone itself or in App Store projects. Continue reading on to find the code. Don't forget to substitute your own user folder into the code (in my case, "ericasadun") for Jonathan's ("schwa").
iPhone devsugar: App Store approval in...one hour?
Approximately one hour after uploading his new application update to iTunes Connect, Bristol-based iPhone developer Rob Jonson of Hobbyist software got the surprise of his week: an official Apple green light. His latest update to his VLC Remote application had been approved and was ready for sale. VLC Remote allows you to control a Mac- or Windows-based VideoLAN playback client from your iPhone, basically duplicating many of the features you'd get from a standard Apple Remote. His update wasn't complicated. "It was a simple problem," he told me over the phone this morning. "One of the buttons stopped working because of a stupid error. I missed a break in a case statement." So he uploaded his bugfix at about 11 PM local United Kingdom time. Just before midnight, he checked his e-mail before heading off to bed. The Apple approval was sitting in his in-box. A recent update, submitted last week, had taken only a day to receive approval. "With 24 hours, I was very impressed. But one hour? I couldn't believe it. Clearly Apple has changed the game." Update: This picture speaks a thousand words. Courtesy of Tom Harris of InsiderApps. This is a different app from Jonson's
iPhone devsugar: Simulating device events with iSimulate
Anyone struggling with the challenge of developing for the iPad, a platform whose hardware has not yet been released, should welcome iSimulate. For just ten bucks, you can test your applications using event inputs from a real device. Yes, you'll be working with the limited geometry of an iPhone -- fewer pixels, not the same device shape -- but you'll gain access to a much wider range of gesture and accelerometer events to help you debug and develop your apps. Using iSimulate involves little more than compiling in a framework and running an iPhone-based application that you download from the App Store. You'll need to add -ObjC to your linker flags and include the Core Location framework. This latter is needed in order to provide simulated compass and GPS events to your app. Once run in the simulator, iSimulate will automatically find that running app and offer to link to it. It took me only a few minutes to bring my Xcode project into iSimulate compliance and get it working with the iPhone. In use, I found the entire process of interacting with my phone to generate events on the Simulator far easier and more intuitive than I expected. I suspect I'll keep using iSimulate over the next few weeks until the iPad debuts and can comfortably recommend it to other devs. TUAW is commonly provided with not-for-resale licenses or promo codes to permit product evaluations and reviews. For more details, see our policy page. Promo code requests are not guarantees of reviews.
SDK devsugar: Re-signing applications
TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on signing already-compiled and already-signed applications with a new custom signature. A while back, I posted about a way to sign already-compiled applications with your personal credentials in order to better allow developer-to-developer distribution. By re-signing an application, it allows you to install it on any of the devices you have registered to your account at Apple without having to go through the fuss and bother of normal ad-hoc distribution. In addition, it makes it easier to develop applications on a contractor's machines, to ship them to a client, and then have them signed and shipped to App Store using the client's identity. A basic command-line solution is as follows. It calls codesign (found in /usr/bin) to sign the application, using the default keychain item that matches "iPhone Developer". It's a handy script, especially for informal beta distributions. #! /bin/bash export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate codesign -f -s "iPhone Developer" $1 There are, however, several problems with this approach. First, it assumes you only want to sign with development (typically "Debug build") credentials. That's not going to work if you need to re-sign for distribution. (Solution? Change iPhone Developer to iPhone Distribution). Second, it assumes you only have one developer or distribution profile in your keychain. (Solution? Change iPhone Developer, for example, to iPhone Developer: Company Name to exactly match just one keychain entry.) Third, it assumes the person doing the re-signing knows how to use a command line. For that, the solution is a little more complicated. Recently, this topic came up on a developer e-mail list that I moderate: how do you make it easier for a non-technical client to re-sign an application, normally for distribution. As a solution, I put forth the proposal that one could embed the above shell script behavior into an AppleScript droplet. After consulting with a few colleagues, and gathering their requirements, I decided to give the project a try. I built an AppleScript application that signs any application dropped onto it. You can find a working copy of the application at my website. App Signer iterates through any apps dropped onto it, checks to ensure whether each file (or bundle, really) ends with an ".app" extension, and then attempts to sign those files using /usr/bin/codesign. Users can choose to sign with Developer credentials, Distribution credentials, or select Other to open a prompt and enter text for keychain disambiguation. (See the screen shot at the top of this post for an example of the disambiguation dialog.) The application displays results for each application, one at a time. Please note the following caveats: I make no attempt to guarantee that the app dropped onto this utility is actually an iPhone app (rather than, say a Macintosh application). When working with on-device keychains, the identity used to sign the application has to match the application id set forth in the Info.plist file for the application, otherwise keychain access will fail. This is a free application. It is offered under the BSD license. Use it at your own risk. Credit always appreciated. The open source github repository for App Signer can be found here. To create the application, open the AppleScript source in Script Editor and choose File > Save As > File Format: Application.
