iPhone Development Blog

App Store rejections is a part of life for us iPhone Developers. Recently there have been several high profile rejection cases that have garnered the attention and response from Apple’s top level management. This is most welcome news!

I genuinely believe that Apple does not have evil intentions when it comes to approving iPhone applications for the App Store. I think the problems that we are seeing are the bumbling results of a process that was hastily put in place and which is still trying to catch up with the flood of new applications and the many intricate policy decisions required. Apple’s self-imposed cone of silence doesn’t help their cause and it frustrates developers to the point of giving up.

This is the first post in a series where I want to constructively add to the discussion.

The meat of this post is on a regular web page that you can reach from the main navigation on this blog. I want to maintain this page as a comprehensive resource for all the technical things you need to think about and comply with before you submit your application to the App Store. I welcome your feedback and additions to the list.

It is my own experience that most App Store rejections are valid and they make sense, at least when they are explained to us. I also think Apple’s recent moves to pay more attention to copyright infringements is good.

However it’s the few cases where the App Store reviewers seem to have gone off the deep end, that we love to talk about. I’ve had my share of these too, and I’m going to dish out the details in the following posts:

• The story of a mainstream book that was too funny to be accepted. I’m sure you will recognize the name of the author.
• The inside story of an app that broke new ground in the App Store and paved the way for a whole new category of apps. For better or worse, depending on your perspective. That app sat in the queue for four months.
• If you think four months was a long time to wait for an app to be approved, wait until you hear about my own personal record.

But before we get to the juicy stuff, please head over to App Store Rejection Reasons.

written by Nick \\ tags: App Store

Lately there is no shortage of rumors surrounding a new tablet device supposedly in development at Apple. Besides satisfying our lust for new shiny gadgets from Cupertino, what does an iTablet mean for us iPhone developers?

Operating System

Given the theme at WWDC ’09 of there being one operating system for Macs and iPhones, it seems obvious that an iTablet would run OS X.

The real question is what type of UI would they layer on top of an OS X core? My guess is an extended version of UIKit. Apple has spent a lot of time thinking about how to build user interfaces for non-desktop devices, and unlike other competitors’ offerings, UIKit is very well designed.

On a small screen like the iPhone’s you are by necessity focused on a single task, and therefore it does not make sense to have a windowing system. On a 10” screen the situation is different, and I hope that Apple doesn’t lock us into a single task metaphor. At a coding level I don’t see why an application couldn’t manage multiple UIWindows instead of the single one you’re used to on the iPhone.

Processor

AppleInsider had a great story about the iTablet, going into a lot of detail regarding the choice of the processor: ARM. Besides being good news for battery life, that is also good news for iPhone developers since that presumably means that the iTablet would be able to run iPhone binaries natively.

iPhone Compatibility

Apple acknowledges that a large part of the iPhone’s success is due to the App Store and the >65k applications available just a tap away. So consider the jump start an iTablet would get if it could run all those apps out of the gate.

Imagine that the iTablet had an iPhone simulator similar to what we’re used to in Xcode. If Apple spent some time on polishing the simulator app and integrating it better with the hardware (e.g. accelerometer, full OpenGL graphics support, camera, GPS) there’s no reason why it could not run a majority of the iPhone apps available on the App Store.

Even if the processor was not an ARM processor, running iPhone apps on the iTablet could be possible just like the Xcode iPhone simulator currently runs code compiled for i386. All iPhone app developers would have to do is recompile their iPhone apps into universal binary style bundles.

Going Beyond the iPhone

Apple has done an excellent job of keeping compatibility between the various iPhone/iPod Touch devices. New hardware features are add-ons that an application can take advantage of, while still working on older devices.

The main challenge of a tablet style devices is of course the screen size. UIKit is not locked in to 320 x 480, but there are no features that make resolution independent graphics easy. You could argue that moving between portrait and landscape modes on the iPhone is a taste of what is to come. If your application can adapt its screen layouts between 320 and 480, then going to other resolutions would not be a quantum leap.

Say that by default the iPhone simulator on the iTablet launches into 320 x 480 mode, but you have the familiar OS X red, yellow, green buttons in the top left corner of the window that could change the size of the window. If the iPhone application is capable of rendering on a larger screen then it just shifts into that mode. (Much like the OS X Calculator changes modes when you click the green button.)

Start Planning Now

While a tablet device is likely to be a smaller market than a phone, it doesn’t hurt to have another outlet for your apps. Start thinking about how your current iPhone apps could make best use of a much larger screen, while keeping the UI simplicity of the iPhone.

Disclaimer

I have no insider knowledge of Apple’s plans. If I did, I couldn’t be writing this post. The above speculations are purely my own, and as such they make sense to me. Please let me know what you think in the comments.

written by Nick \\ tags: Rumors

I just got accepted to speak at the 360|iDev conference in Denver at the end of September. Unfortunately I missed the first 360|iDev conference in San Jose this past spring, but I heard that it was very good. Given the long list of distinguished speakers at the Denver conference, I’m fully expecting this one to be just as good. Check out the details here: 360idev.com

Note: The similarities between our company names, 360mind and 360iDev, and our location in Colorado, are purely coincidental.

The topic of my talk is UIWebView – The most versatile class in UIKit

Here are some of the tips and tricks you will learn in the session:

• Load images, CSS and JavaScript from your app bundle.
• Display more versatile result lists than UITableView.
• Use dynamic CSS to resize text in response to gestures.
• Receive touch events that are normally hidden by UIWebView.
• Use JavaScript to interact with UIWebView content.

If you have other questions or subtopics related to UIWebView, please let me know in the comments below. I’ll try to work in as many as I can into the presentation.

written by Nick \\ tags: 360|iDev, UIWebView

Sorry about the long absence from the blog. I’ve been busy working on several 3.0 projects. One of the apps I worked on was showcased during Apple’s keynote at WWDC. That was really cool!

• 3.0 was released to the eagerly waiting public today. For us developers this is mostly an non-event since we’ve been working with the new features for quite a while. Just one note on upgrading your iPhone: During the upgrade process there is a step where you phone has to be re-activated and I’ve read reports that this activation server has been struggling under the immense load today. You may want to hold off slightly with upgrading your primary phone until the frenzy is over, otherwise you might temporarily end up with a phone that is only capable of making emergency calls. Friday is probably also a bad day since the 3G S will go on sale. At least Apple had the sense this year not to launch both the software upgrade and the new iPhone on the same day.
• The new App Store is live with parental controls. If you haven’t logged in to iTunes Connect for a while you might want to do that and set the parental control settings for your apps. I don’t know what will happen if you don’t specify a rating. But unless you have over 500 apps on the store like one of my clients, then it’s a pretty quick process. And it will provide good information for you potential customers.
• Now that the NDA is lifted for 3.0, expect to see some 3.0 related posts here. How do you write apps that take advantage of 3.0 and still work on 2.x? Anybody struggling with In App Purchases? Stay tuned.

written by Nick \\ tags: 3.0

iPhone development us usually very enjoyable using the Apple’s excellent development tools. However, Apple’s user experience experts must have been on vacation when they designed the iPhone code signing process. Particularly the error messages seem to be designed to confuse rather than help.

This happened on a project where we have multiple iPhone developers both at our company and at the client working in parallel. One day out of the blue we were greeted with the dreaded “unexpected error (0xE800003A)” when deploying to our development devices. Since it’s been about a year since the iPhone development program started, the first thought was that a certificate had expired.

A a wild goose chase ensued following Craig Hockenberry’s sage advice regarding expired certificates, with several variations and extensions, and other fascinating dead-ends. Still same unhelpful error message.

Finally we discovered that one developer had created an AdHoc configuration and in that process created the Entitlements.plist file. That is all well and good. But he had added Entitlements.plist to both the AdHoc and the Debug configuration. Not so good.

After removing that one line in the build settings, normality was restored.

Hopefully this will save someone else a few hours and some sanity.

Other good code signing resources:

• how to fix iphone code signing errors

written by Nick

Allowing 3rd party iPhone applications to run in the background is an often requested feature in the official SDK. Apple has responded that they can’t do that primarily due the increased, and unpredictable, battery drain. However Apple is also notorious for claiming that they are not working on something and they have absolutely no interest in working on it, until they surprise everybody with a working solution. With that in mind I decided to poke around a bit in the new 3.0 SDK.

There are 1,000 new API:s in 3.0, so there’s a fair amount of ground to cover, but a new framework called AsyncPRocessIngLibrary caught my attention. I have not been able to find any documentation for this framework, but it’s not in the PrivateFrameworks directory, so it’s presumably fair game.

Here’s an example of what you can do with this library that was discovered today:

UInt32 numProcessors = MPProcessorsScheduled();
/* Schedule task across available processors.
   Major hint of new hardware... */
for (n = 0; n < numProcessors; n++ ) {
   MPCreateTask( MyTask, kMPStackSize, NULL, NULL, taskOptions, taskID );
}

This is all pretty standard multi processing code. What’s new and interesting here is the taskOptions:

enum {
   MPTaskOptionNone                   = 0,
   MPTaskOptionTerminateOnAppExit     = 1 << 0,
   MPTaskOptionTerminateOnThreadDeath = 1 << 1,
   MPTaskOptionTerminateOnSemaphore   = 1 << 2,
   MPTaskOptionKeepRunning            = 1 << 3,
   MPTaskOptionLurad                  = 1 << 4,
   MPTaskOptionGetauscht              = 1 << 5
};
typedef UInt32 MPTaskOption;

Most of these flags are self-explanatory, but unless you set the 4/1 bit, they don’t behave as expected.

Example:

UInt32 taskOptions = (MPTaskOptionKeepRunning | MPTaskOptionLurad);

It’s important that before attempting to launch your background process, you first need to ensure that the device you’re running on is capable of this:

if ([[UIDevice currentDevice] isProcessFoolEnabled]) {
// start your process here
}

written by Nick \\ tags: humor

The other smartphone vendors who have been working like crazy to catch up with Apple ever since the original introduction of the iPhone, were set back another year today with Apple’s preview of iPhone OS 3.0.

Some of the other touch-like phones currently available are actually not bad phones in themselves. But any smartphone today is compared with the iPhone, and that’s where they fall down. Palm who has recently gained some attention and interest for their Pre, will now face off with the iPhone 3.0 at their launch in June. You have probably already forgotten the shortcomings of the first iPhone software release. I can’t think of any smartphone vendor who has hit it out of the park with their 1.0 release. Now Apple has had two years and the help of 30 million customers to refine their software. ”Not one of those people will still be using an iPhone a month later.“ Right.

Other blogs have covered the 100 new features of 3.0, so I will not rehash that information. And the 1,000 new API:s are covered by the NDA, so I can’t discuss them either. But I would like to emphasize the new business models. These changes are HUGE.

The initial App Store model only allowed single apps to be purchased for a one-time fee. This led to the proliferation of books as apps, and apps where it would be natural to purchase additional content but that was verboten. (We actually implemented mobile content purchases for iWallpaper, but Apple rejected it.) When asked at the time, Apple plainly stated that they did not have a solution for other business models.

Now they do. In spades.

• The ability to purchase content separately from the app. Suddenly ebook readers on the iPhone make a whole lot more sense.
• Subscription billing. Get continued access to a service (games, enterprise services), or receive new content on a regular basis (magazines, videos).
• Make purchases from within applications. This feature alone probably added another $1B to the App Store business for Apple.

You have already seen a lot of content made available in the form of iPhone apps for the sole reason that you can easily charge money for it; unlike the web in general where everything is expected to be free. With these changes Apple will become the largest seller of digital products of all types. If you can digitize it, it will soon be available for sale in the App Store. (And why limit the store to iPhone clients? Sell information products for any computer. Notice that it’s not called the iPhone Store…)

Competitors have been scrambling to launch App Store clones, with one of the larger alternatives having just barely put payments in place. (Although, handling micropayments from mobile devices in 77 countries should not be belittled.) Now Apple lapped them again.

I’ll let other people continue to whine that “there really wasn’t that much unexpected” and that this was “Really pretty minor stuff“. You’ll have to excuse me, I have a dozen new apps to write that just became possible. And a few new business models to explore. This is going to be just as much fun as last year when the SDK was brand new!

written by Nick

I’m always appreciative of other bloggers and web sites who link to this site, so when I see a new referral URL in the logs, I typically check it out.

This time it turned out to be a well written report about iPhone business opportunities, and iPhoneIncubator.com is mentioned as a good source of information for SDK developers. Thanks for the link Kisky!

You can download the free report at http://theamazingiphone.com/

written by Nick

I have a great idea for a new iHouse. This is relovutionary; nobody has every thought of this idea before. Now I just need to pardner with a very solid iHouse builder to make this realty. I come up with the ideas, you bring the expertise!

You must have at least 2+ years of experience with building iHouses, dealing with Mapple’s approval processess and selling on the Hip Store. Please send me all examples of relevant, prior work so that I can try them out for free.

This is a very simple house. For an experienced iHouse developer this project should only take a few days hours to compete. So I’m being extensively generous in offering to share the guaranteed-to-come future profits with you: 50/50.

This iHouse idea is so super extraordinary that you need to be prepared sign tripplicate NADA and non-complete contract.

If you are good and professional I will email you back.

—

It cracks me up each time I see these messages on Craigslist and other message boards. The above was aggregated from actual posts. A few minor edits were made to protect the innocent. Now back to our regular scheduled program.

written by Nick \\ tags: humor

Push API

The push API that was announced at WWDC ‘08, and scheduled to be live in September 2008, will finally debut in 2009.

Side prediction: There will be per-message fees associated with the push service.

MobileMe API

An API that was hinted at during WWDC ‘08 to allow programmatic access to your data in MobileMe will be introduced.

I can’t think of a better way to lock in users to the iPhone/Apple world than an API to MobileMe. This will allow iPhone apps to really use and integrate deeply with your calendar and other features of MobileMe.

More APIs

Apple will release more official APIs that allow developers to access more features of the iPhone, e.g. SMS, Bluetooth, video recording, iTunes music, the phone itself.

Much of Apple’s marketing depends on being the purveyor of the coolest gadgets. So Apple cannot afford to see the most innovative mobile apps to be developed only for other competing platforms. 

No Major Hardware Releases

Developers are just beginning to understand the iPhone and we are starting to see some innovative apps. Fragmenting the platform with new form factors at this point would be bad. Ask any J2ME developer how much fun it is to play the “write once, test everywhere” game.

Better App Store

The organization of the App Store will be vastly improved with more categories, better keyword search, top lists that are not completely tilted towards $0.99 apps.

Reusing the iTunes infrastructure for the App Store was a stroke of genius, and probably necessary to launch the App Store in the given timeline. But now it’s clear that apps and music have diverging characteristics: 

• You typically don’t search for music to meet a specific need. 
• Pricing.
• For music, audiobooks and video, iTunes is just one of many distribution channels.

More App Store Commerce

Apple will introduce more commerce options for the App Store, e.g. subscriptions and separate billing for content.

The proliferation of ebooks as separate apps that clutter up the App Store and your iPhone home screen, could easily be avoided if there was a way to charge for content separately from apps. Add the ability to sell subscriptions or other means for developers to get recurring revenue, and we’ll see some really innovative apps and business models in the App Store.

No Trials

Probably the App Store feature most requested by developers of serious/expensive apps is to allow for free trials. I predict that this wish will not be fulfilled in 2009.

There should not be any major technical reasons preventing free trial versions of apps since FairPlay DRM already supports rentals that expire after a set time. My guess is that it’s a business decision and Apple makes too much money from “regretware”. It would be very interesting to be a fly on the wall at Apple during the discussions of revenue vs. a better quality App Store. Personally I hope I’m wrong in this prediction. 
 

What are your iPhone predictions for 2009?

written by Nick \\ tags: predictions