Talk Funnel

Ramin Firoozye's (occasional) Public Whisperings

Simple Solution to iPhone 4 Antenna Problem

Posted by: Ramin on July 2, 2010





I’m not an antenna engineer but it seems like the simplest solution would be to move the ‘gap’ between the two antennae where it’s unlikely to be covered through casual touch. This would work for both left and right-handed users.

From a hand-placement point-of-view the ideal spot would be in the middle of the cable connector but that could introduce structural issues with the plug.

A Visitor’s Guide to WWDC and San Francisco

Posted by: Ramin on June 4, 2010


It’s time, once again, for the annual love-fest that is WWDC and that starts next week. I’ve been to each one since the iPhone launch (I know, that makes me a relative newbie) but having spent a good chunk of the past two decades living in San Francisco, I figured I’d combine tech-tips for first-time attendees with social things to do for out-of-towners.

Tech Tips

  • You can register and get your badge on Sunday, the day before WWDC starts. That saves you a bit of time doing it on Monday when everyone stands in line to get into the keynote speech. If you do go in on Sunday then you may want to pop into sfMacIndie at Jillian’s in the Metreon at 6pm. It’s across the street from Moscone West. Grab a drink and chat up fellow developers. You may want to pace yourself. The next day is the big event and you want to be able to get there early — at least by 8am if not sooner. They don’t start letting you in until 9:30am so wear comfy shoes. Make sure to say hi to fellow line-standers as you hop from foot-to-foot trying to stay warm.
  • This is San Francisco. In June. This means chances of early morning sun are slim to none. Standing in line for the keynote means no moving for hours in the cold, blowing fog. Unless you’re seriously thick-skinned (like the poor, freezing iPorn girls of last year) bring layers and be prepared to discard them as the day wears on and temperatures rise.
  • The on-screen keyboard on the iPad is nice, but don’t forget your laptop. You will want to take notes. Lots of notes. And fast. As Marco Arment says WWDC is one giant info-dump and there is no way to absorb everything. You’ll need a real keyboard to keep up. I like to create separate folders for each session and save note files in TextMate. Under each folder you can also save sample code for the sessions. Then I throw the whole top-level folder into TextMate as a project so I can quickly search and find what I’m looking for. I suggest you try to capture as much as you can while there and take time later to go over things. They were pretty quick about posting up the videos of each session last year, but there’s no replacement for one’s own notes.
  • Head down to the lunch area on the ground floor around noon. The food’s nothing to write home about (yeah, I’m being polite) but it’s a good chance to meet people and find out common interests. Most of the other times you’ll be standing in line or in-session. This is your chance to have a decent conversation and who knows, learn a thing or two from fellow developers. I’ve always enjoyed these random encounters.
  • If you have questions or want to get feedback from Apple engineers and designers, sign up for the labs and do it early. Spaces fill up fast, especially for the UI Design reviews. Drift down to the cafeteria area on the ground floor and find out what the sign-up protocol is. On the rare occasion there isn’t an interesting session, hover around the lab areas. You’ll pick up great info just by listening to Apple folks explain how things work.
  • Try to bring a Verizon or Sprint MiFi. The Apple-supplied WiFi network is OK, but most of the time it gets overloaded. Forget AT&T’s 3G network. It’s a joke. With most people carrying a MacBook, an iPhone, and an iPad, your best bet is to bring your own network. The downside to this is you probably won’t be able to access the WWDC attendee-only content accessible to those on the network there. But once you’ve snagged all the goodies you can switch back to your own network and zip along. [Update: OK, maybe not such a good idea if everyone turns them on at once.]
  • If you bring your own network, make sure you set a secure password for access to the wireless hub. And for crying out loud, don’t make it the 40-bit WEP. Go for the WPA2. Way too many people running Wireshark or Kismet out there. Also, while you’re at home set up all your network devices to log in, then set the hub to not broadcast its SSID. That way all those other people around you won’t have to scroll through a gajillion wireless hotspot names.
  • Bring a comfortable backpack. The one they’ve been handing out to WWDC attendees the last few years is pretty minimalistic. If you need space for all your gear (and an extra sweater) then bring your own. Don’t worry about food, unless you need to snack often. They provide bagels and cookies and whatnot to keep you fueled up.
  • Sync up your dev iPhone or iPad at home and back everything up. There’s a good chance there will be a new SDK drop there with a bunch of new goodies. Recommend you not try to download over the WiFi. Walk over to one of the round tables outside the session rooms and plug into the Ethernet firehose. Much, much faster.
  • Please, oh please remember to turn down the volume on your phone/iPad/Mac during sessions. Yes, you know you’re on Twitter and now we do too. You can thank chirping bird man for that.
  • If your backside is sore from all the sitting down or you feel like taking a quick nap, there are bean-bags on the top floor. First come-first serve.
  • If you’re looking for a job or have a job to post there are white-boards in the bean-bag lounge area.
  • Stash a power-strip in your pack — it’s a good way to make friends.  Among tech conferences WWDC is one of the better ones for providing power to attendees. Even so, they sometimes run out of plugs. I’m partial to the Monster Outlets to Go units. They’re small and you can charge up most of your devices in one sitting. Some models even come with built-in USB charging ports. While you’re at it remember to bring separate power-to-USB adapters for your iPhone and iPad. The iPhone is happy with the small 5W units but the iPad needs the beefier 10W adapters. If space is a premium you may want to grab a couple of retractable USB cables too.
  • If you’re missing anything or forget to bring any hardware, your two nearby geek supply outlets are the Apple Store on Stockton Street and Central Computer on Folsom at 4th.

OK, so much for the conference itself. What about the social life?

Organized Events

Here’s a good reference for organized after-session gatherings: On Tuesday between 7:30 and 10:30 pm, however, a lot of people will likely head over to the Apple Design Awards ceremony. A large number will stick around for the Stump the Chumps Experts session. On Thursday night Apple throws a bash in Yerba Buena Gardens. You’ll need your WWDC badge to get in. If you’re of drinking age you’ll need to get a wrist-band at Moscone before heading over. Pace yourself on the booze if you plan on hitting any other places afterward. You get all the food and beer you can consume plus a (surprise) live musical act. And there’s still Friday’s sessions left.

Quick Eats

If you get tired of eating pre-packaged sandwiches and are hankering for something slightly different, here are a few places within easy walking distance of Moscone. However, no guarantee they’ll get you in and out in time for the afternoon sessions:

  • Food court at Metreon – Walk across the street, grab yourself something and go sit outside in Yerba Buena Gardens to decompress. Absolutely glorious if it’s sunny.
  • Taqueria Cancun – Bit of a hike up on 6th and Market, but decent enough Mexican fare.
  • Out the Door – (sorry, Flash site) is by the same people who run the outstanding Slanted Door in the Ferry Building. This one’s in Westfield (Nordstrom) shopping center on Market and 5th.
  • Specialty’s – Great sandwiches. Best part is they have an iPhone-friendly ordering service. Closest one is on New Montgomery between Mission and Market.
  • The Sentinel – I haven’t eaten there yet, but people keep recommending it and it’s top of my list for lunch places to try. Fancy-looking sandwiches.


The swill they serve at WWDC may be fine for getting you over your previous night’s hangover, but you owe it to yourself to get some decent coffee while in town. Good places within walking distance:

  • Blue Bottle – Just go. Get the Latte if you’re in a hurry or the drip coffee if you have time. Don’t worry, it’ll make sense once you get there.
  • Peet’s – Closest one is on Mission between 3rd and New Montgomery. Strong coffee. Puts hair on your chest, whether you want it or not.
  • Chatz – Bit of a hike on 2nd Street between Howard and Folsom, but good place to go if your feet need some stretching.

Local Watering Holes

For some reason after a day of technical brain-melding a lot of people are extra-primed to kick back and partake of adult beverages. Go figure. If that’s what you’re looking to do, here’s a number of local hangouts where you are sure to bump into fellow WWDC attendees:

  • Jillian’s – It’s across the street, doubles as a sports bar, has a large selection of beers on tap, and has pool tables in the back.
  • Thirsty Bear Brewing – Upscale brewpub. Decent beers and Tapas-style dishes, only a block away.
  • Chieftain’s – Grungy Irish pub. First stop for a lot of die-hard old-timers before they inexplicably head all the way out to…
  • Tommy’s Mexican Restaurant – A favorite of Apple folks, but it’s all the way out in outer Richmond. With places like Tres Agaves or dive bars like City Bar in the Mission you’d think someone would try to find something more accessible. It’s far away, in the fog zone, and the place is usually mobbed but if you do decide to head out to Tommy’s try to snag a ride with someone else–preferably a teetotaler. There’s a chance you’ll end up slamming tequila shots and trust me, you won’t want to be driving, flagging down a rare cab, or being at the mercy of Muni late at night.
  • Harlot – Decent, but small. Odds are there will be a line to get in.
  • XYZ bar at W Hotel – Upscale drink spot. Excellent place to hang out if you’re on a corporate expense account or your app just cracked the Top 10.

A little further out — but still worth it

Want to pretend you’re a local? Some are a bit of a walk, but if you get in with a group of fellow developers and want to get out of the Folsom/Howard zone, here are a few places to try (in no particular order):

  • Johnny Foley’s – Irish Pub within walking distance. It can get a bit touristy, but there’s nightly live music and (natch) Guinness on tap.
  • Zeitgeist – Sort of a cross-road of cultures and styles. No other way to describe it.
  • Orbit Room Cafe – Best damn Bloody Marys in town.
  • Hotel Utah – Grungy local spot, sometimes with good music.
  • Bottom of the Hill – Great place for local live indy bands. Out in Potrero Hill (accessible via the Muni T-line) but the music’s usually worth the trip.
  • AsiaSF – The waitresses double as transgender stage performers — and they’re awesome.
  • 21st Amendment Brewery – Big with the local tech types floating around 2nd street. Decent brews.

Obviously I’m leaving a lot out, but this should give you a decent starting point. Feel free to post any corrections or favorites in the comments. Hope to see you all at WWDC. If anyone wants to look me up and say hi, I’m @raminf on Twitter.


Update: Added a few more places — for those in a hurry to get back to hacking and getting their mind blown.


AutoPark: my first iPhone app

Posted by: Ramin on February 1, 2010

There’s been a lot of behind-the-scenes activity around these parts and I hope to be posting more actively from here on out. But first I’d like to announce my first iPhone product on the AppStore, published under the FrolicWare label:

AutoPark: Say Goodbye to Parking Tickets. It lets you keep track of time on your meter so you avoid parking tickets. It uses push notifications to send out an early-warning and a separate meter expiration alarm. The intent behind it, however, was to be an all-in-one driving assistant so it does a few more things, like:

  • Help find a parked car using the GPS.
  • Remember where you parked in a parking lot (floor, section, color zone, etc).
  • Work with or without push alarms enabled (if away from the data network).
  • Track time on parking meters or with pre-paid parking machines.
  • Attach a text and picture note — handy for remembering what that rental car looks like.
  • Email all parking data out via a rich HTML message with embedded map and links.
  • Get a list of nearby local services (bank, gas station, bathrooms) you might need when you’re parking your car or right before leaving.

it’s available for $4.99 on the AppStore and the first user reviews have been pretty positive. It’s already made it into MacWorld Magazine!

But this isn’t just about a single iPhone app. There are a lot of posts rattling around my head that I’ll be rolling out gradually: from the evolution of the UI and graphic design, to running a one-person development shop, the economics of app development, the transition to iPad, tips and tricks on developing a push server, and the process of marketing an iPhone app. From conversations with fellow iPhone developers I get the feeling this is information that could be useful to others in their own efforts.

When the AppStore was first announced, I remember thinking this is the first time an individual or a small team can easily bring a software product to market without having to worry about a lot of the hassles of full-bore software publishing. I still think that’s the case, but I was off by an order of magnitude on the it’ll be easy department. I’m going to write about this experience because I think it’s good to get these things out there for all those people dreaming about starting their own gig.

In the meantime, here’s a presentation I gave at the January 2010 Silicon Valley iPhone Developer Meetup on development of back-end servers for iPhone apps. I tried to avoid making it about a specific product but it relies heavily on the experience of putting together the AutoPark push notification server.

This is only the first app out of the chute and this is the first post on what goes on behind the scenes. So stay tuned…

P.S. I’ll be showing off AutoPark (and maybe a peek of an upcoming app) at MacWorld Expo in San Francisco February 9-13, 2010 at the Mobile Application Showcase. This is the first year they’re featuring iPhone apps so it’ll be interesting to see how they’re received in a historically Mac-only conference. It’s also my first time as an exhibitor (and yes, I’ll be blogging about it).

Feel free to pop over and say hi.

Update: AutoPark won Best of Show at Macworld 2010 and got 4.5 out of 5 mice.

Eval iPhone apps: the good, the bad, and the ugly

Posted by: Ramin on October 16, 2009

[ This ended up being a fairly long and somewhat technical post. I edited it down as best I could, but I think it’s an important topic in the iPhone world and something that has to be laid out in its entirety. I suspect it won’t be of much interest unless you’re an iPhone app developer, a highly technical end-user, or a masochist masquerading as a layperson. You have been warned. – Ed.]

The news dropped like a bombshell on the iPhone developer community yesterday: Apple is now allowing In App Purchasing in free applications. Hip Hip Hooray!

But wait. What does that mean?

I won’t repeat what I’ve already said in a previous post but the upshot is it’s now possible to ship a free application on the iPhone appstore then ask the customer to purchase an ‘unlock’ token once they’re done evaluating it. The common consensus (as much as what is said on blogs, mailing lists, and twitter can be considered so) in the developer community is that it’s a positive move. Marco Arment (the developer of Instapaper) called it a “… great move for both users and developers.

The Good

With this seemingly small change in policy consumers can (finally) try out an app before they have to pay for it. No more buying an app then realizing it doesn’t work and getting stuck with a dud. The immediate effect will most likely be fewer impulse sales–which means lower short-term revenue–but in the long-term users are more likely to be happy customers instead of accidental ones.

It’ll also mean that app developers should be able to increase their asking price for well-made apps, because users will have had a chance to take it out for a test run. On the other hand, there’s no guarantee this will end up increasing per-app revenue given the low conversion ratio from free to for-pay apps. In fact, I’d strongly question the logic of $0.99 apps even bothering to offer an evaluation version. All those impulse and let’s try this purchases probably account for a more substantial portion of sales than most developers care to admit.

But the initial developer reaction seems to be positive. Most indy developers in it for the long run would rather have fewer happy customers vs. a lot of unhappy ones.

The Bad

First, let’s take a little detour and define what we actually mean by an evaluation app.

In the regular computer world (versus, you know, the iPhone Candyland) a developer creates an application then offers it to the user for evaluation in one of two possible ways:

  1. Degraded mode: this is where the application has some of its features disabled, for example, no saving or only printing with a watermark. The user gets to experience what the app does, but only up to a point. How much functionality is included is up to the developer but it’s in their interest to allow as much as possible to make the sale without giving up too much.
  2. Time-limited mode: this is where the application is fully functional for a limited amount of time (usually two weeks to 30 days). After that either the user buys the app or it stops working. A slight variation is where the app reverts to degraded mode when the eval clock runs out.

The main difference between a Time-Limited and a Degraded app is what the developer allows the user to experience during that period of time. That’s an important distinction because the end-user experience was noted by Apple as the main reason they initially didn’t allow In App Purchasing in free apps. The reasoning was that a user should not be told an application is free, then be forced to pay for it. But it appears that concerns for application piracy and loud complaints from developers have overridden those worries. But the problem is still valid. Hopefully Apple will make changes to the Appstore to better communicate the actual fully unlocked price to avoid end-user confusion.

There’s also a subtle issues unique to the Time-limited app on the desktop and that is what to do when the user tries to get around the evaluation restrictions — ostensibly to keep using the application in full evaluation mode ad infinitum without having to pay. The two most common methods are settings back the system clock (to make the app think the eval time hasn’t run out), or to uninstall then reinstall an app to reset the meter.

The solution to both of these problems is fairly simple: the app can write an already run token and periodically save a time-stamp in such a way that persists beyond an application getting uninstalled. Then it’s fairly easy to detect if the clock has moved back or if an app has been reinstalled.

But that’s the desktop. What about the iPhone? The problems are the same. Some users may be tempted to keep an eval app (especially a high-priced one) running. Can the clock reset trick work? Yes, it can. Most users leave their phone’s clock in its default auto-update mode so they can use their phone to keep track of time. But it’s fairly easy to reset it manually. All you have to do is run the Settings application, go under General tab and disable Set Automatically then set the clock to whatever date and time you want. The down-side to this is that so much of what you do on a typical iPhone relies on the system clock so it’s unlikely someone will be willing to put up with having a constantly skewed clock on their phone for the sake of just one application. But you never know.

What about the delete/reinstall method? On the iPhone, once an app has been deleted all associated files are also removed so there would have to be a way to save a persistent token that outlasts the app install-delete cycle. On the iPhone, unlike the Mac, no such place exists. The app developer could always save the unique device ID (UDID) of the phone on a server, but the Apple developer license explicitly forbids saving private user data off the phone. Does the UDID count as private data? It certainly is unique. We’ll have to see. But at the very least, it means each developer has to maintain server infrastructure to track this sort of thing.

So as it currently stands it’s too easy for a user to simply remove and reinstall an app or to fiddle with their clock and continue using an app in its fully-functional eval mode. I’m pretty sure this isn’t what Apple had in mind when allowing In App purchases.

That leaves Degraded mode. This means that the application the user would download from the Appstore for evaluation wouldn’t be the full version. In an earlier draft of the developer license agreement shipping this type of app was explicitly forbidden. In the newly revised version, well, it’s not so clear. In Attachment 2.4 it is clearly stated that:

2.4 You may not use the In App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. An In App Purchase item must either already exist in Your Application waiting to be unlocked, be streamed to Your Application after the purchase transaction has been completed, or be downloaded to Your Application solely as data after the purchase transaction has been completed.

This means that the full application functionality must be installed on the phone–no way to send up updated binaries. So all the code is there ready to go but a little key is needed to unlock it. On the desktop this type of app is derisively (and deservedly) called crippleware.

In other words, as of today, what Apple is allowing app developers to ship is crippleware for your iPhone. I could be wrong on this but this clearly falls under the category of Unintended Consequences.

The Ugly

The user plays with the eval app for 30 days (or so) then purchases the unlock token via In App Purchasing. The token is saved on the system so from now on the app launches in its unlocked state. But what form is that token going to take and where is it going to be stored? Given the current sandboxed architecture of the iPhone app, There are two places where an application can actually write data:

  1. The filesystem under the application’s Documents folder. This can be a text file, a user preference plist, a record in a SQLite database, or a CoreData store.
  2. In the keychain as a secure key/value data item.

Apple has intentionally stayed out of the business of what shape or form this add-on functionality or unlocking feature should take. It’s up to the individual developers to decide but odds are it will be one of these two methods.

Trouble is both these methods will actually make it easier for apps to get pirated.

On a regular iPhone no app can cross the sandbox line and access another app’s private data. But on a jailbroken phone no such lines exist. So a few minutes after the app is installed on a jailbroken phone, that special token can be easily extracted and plastered all over the internet. Now you don’t even need to resort to apps like Crackulous to get your free fully-functional apps.

The solution is for each individual app developer to implement tighter security around the application, by implementing secure unlock tokens, perhaps even tied to a specific handset so even if they’re removed from a single phone they won’t be usable on any other phone. But that involves knowing quite a bit about the pros and cons of cryptography and your typical iPhone app developer is not going to have the time and patience to implement anything like that.

So they’ll take the quick and expedient way–they’ll offer crippleware and save the token into a user preference plist or keychain — and hope and pray nobody bothers looking there. Or they’ll sign up with outfits like Urban Airship, iLime, or Push.IO to take care of it for them for a fee.

But this doesn’t mask the fact that with no Apple-defined standard, it’s going to be a free-for-all.

The final bit of ugliness heading our way has to do with user reviews. In the early days of the AppStore anyone could leave reviews — regardless of whether they had bought the app or not. This rendered the system useless since most of the initial write-ups consisted of, um, price-resistant customers (endearingly called freetards by developers) complaining about the price, no matter how low. It didn’t take long for Apple to clamp down on this by requiring only those who had actually purchased an app to review them. This substantially cut down on the noise and helped keep Appstore reviews an important part of the consumer decision-making process.

But now with the advent of free evaluation apps we’re going to go back to the halcyon days of price-gripes, where a user will download the free version of the app, take a look at the price for obtaining the unlock token and submit a 1-star review, complaining about, yes you got it, the price of the app. The current AppStore filter will not work since they’ve officially downloaded the app and technically count as having purchased the app.

One step forward. Two steps back. In other words, it’s going to get ugly. Again.


You’ve been so patient. I won’t keep you waiting. Here are a few steps Apple needs to take for this eval system to work:

  1. Offer a simple, official API for supporting both Time-limited and Degraded evaluations. This means associating some application metadata with each app when it’s installed and forcing Springboard (the iPhone application launcher) to honor these settings before running the application. Springboard already does this when it installs an app–that’s how the App Store application updated can tell what version you’re running vs. what’s on the store.

    To prevent the remove-reinstall workaround, there has to be a way to save some information that lives outside the sandbox and survives application removal. This can be on the phone or on a server. Again, Apple already does both these things. It saves data to the system keychain and it keeps track of what apps you’ve “bought” on the AppStore (so when you go reinstall, it knows not to charge you twice). So it would be easy for them to let the app-developer mark the application as eval, whether Time-limited (and or how long) or Degraded.

    I would even argue that anything having to do with application installation or unlocking belongs in the AppStore/OS domain, not left to individual applications. Anything having to do with In App purchasing of extra grenade-launchers, leave it up to the app.

  2. Far, far more importantly (and I can’t emphasize this enough) Apple should provide a simple API for an application to verify that the current user has purchased the app. This will do far more to cut down on application piracy than allowing free evals. The app developer can periodically and at random times invoke this API and ask two simple questions: Has the current user bought this app? and When?.

    A developer would be wise to sprinkle calls to the API throughout the app. Yes, the application binary can be patched and the API call removed, but that’s a higher wall for your typical cracker to climb than simply modifying a single entry in a text file.

  3. In the absence of a network connection, the default would be to let the application run a limited number of runs (until the user gets back to the network).

    But what about the When? question? The answer would be a timestamp indicating when the user paid for the app. That piece of information is important to app-developers who currently have multiple free/pay versions of applications on the appstore (or who want to continue using that model). For these folks to move from a free/pro model to an eval/buy model means that their end users would have to obtain a new version of their application. There would have to be a way to tell whether the current user paid for the full version of the app during the pre-eval period and not force them to go through the whole purchase cycle again.

    I should also emphasize that with this API the application will never have to be given access to any private user-credentials. Something like the following added to UIApplication will work wonders to ward off app piracy:

    + BOOL isAppPurchased;
    + NSDate* dateOfPurchase;

  4. The last thing Apple could to do help eval/buy apps a success is implement a policy where only users who had purchased the unlock token would be allowed to post comment and reviews on the AppStore. Let’s maintain the status quo instead of taking a step back. The problem, however, is given the totally unstructured way the current In App Purchase model is implemented, there is no viable way in which an extra rocket-launcher token can be distinguished from an unlock application token.

    I would argue that unlocking eval applications, verifying proper ownership, and restricting access to the review system should be the responsibility of the entities that control application installation and launching–i.e., the operating system and iTunes–instead of individual developers. But in lieu of that, Apple should give developer tools to properly implement an evaluation system that welcomes legitimate users and cuts back on potential abuse.

In summary: The In App Purchase mechanism is a great system for supporting application add-ons. But it’s wholly unsuited for supporting eval applications and does nothing to fight application piracy. Having properly implemented eval apps is important to the future of this ecosystem. Apple shouldn’t leave it up to individual developers to figure out how to get there. It should be part of the core functionality of the operating system.

Problems with Push

Posted by: Ramin on September 30, 2009


I agree with most everything Karl Adam says about the limitations of the Apple Push Notification Service, especially the problem with its failure to stack notifications so they’re not missed.

I posted a bug report a while back (rdar://7054632) offering a simple solution to get around this particular problem: save each incoming push payload into as a separate entry. That way if I get a push and don’t have time to get to it I can ignore it and come back to Messages later on and retrieve it and all received Push messages are kept until I choose to get rid of them.

The entry could be in the form of a special URL link that shows the alert message, but when clicked generates the same JSON payload format as a regular push event and invokes the app in the same manner so no extra coding would be needed (OK, maybe just a little bit of code on the server to check against processing duplicate requests). It would take care of a lot of problems with push usability.

An even more pressing issue I have with Push is if you are on a WiFi network behind a bunch of firewalls and more than one NAT server. This happens often in corporations or in homes with multiple routers acting as range-extenders. In these cases pushes fail to reach you — until you get back to a 3G network.

For some people Push is doubling as a remote event timer (since Apple won’t let us access the phone’s alarm database or submit local cron tasks). This makes it really hard to issue reliable time-based alerts.

If Apple would just open up true background tasks and/or timed alerts and let the user decide whether they trust an app to let it access those services (much like location-based or push services) a lot of these hassles would go away.

Also, a European friend brought up that whereas SMS is included in most phone plans, push incurs data usage charges. Could be a hassle if you’re traveling and continue getting pushes.

Over all, I’d say push on the iPhone is a work in progress. As much as I’m intrigued and excited by its potential, I’m frustrated by its current implementation and limitations.

Semi-Modal (Transparent) Dialogs on the iPhone

Posted by: Ramin on September 29, 2009

Popping up a modal dialog on the iPhone is a fairly straightforward process:

modalDialogViewController *modalController = [[modalDialogViewController alloc]          initWithNibName:@"modalDialogView" bundle:nil];  [self presentModalViewController:modalController animated:YES]; [modalController release];

Dismissing it then is a simple matter of the modalController invoking:

[self dismissModalViewControllerAnimated:YES];

But what if you want to show only half a page’s worth or maybe you need the underlying view to continue being available for user viewing or interaction. Or maybe you want to show a pop-up toolbar where users are asked to choose something before continuing. You might think “Aha! I’ll just have my modal dialog view be half as tall and make the background transparent.”

Go ahead, give it a try. We’ll wait… (* … the girl from Ipanema goes walking … *)

So now you know that the standard modal dialog can only be full-screen and maintains a solid black background. What’s more you can’t interact with what’s behind it because, you know it’s modal — and modal means users shouldn’t be able to do anything else until they’re done with the front-most task (unless you’re the search box in the Contacts app in which case apparently it’s OK to be kindasortamodal).

So what we’re going to do is have a view that can be modal but takes only part of the top view, the space above it remaining visible. What’s more, you can choose to have it so tapping on the background view hides the modal view, or even go full-bore and let the background remain responsive to user input. This technically makes the view semi-modal so let’s ignore the sirens and the UI Police banging on the door and go with that.

The first thing you need is a view that has something interactive on it. The easiest way to build one is in interface builder, so go ahead and make yourself one. For the sake of expedience make it only a fraction of the screen. Here’s an example of a half-height view along with some user controls. The background is set to fully transparent. The view is connected to a UIViewController that reacts to user input:


In this case, the view is the same height as the whole screen because we want the upper portion to be see-through but not react to user input. If we wanted it to be truly interactive, we could make the view height be as tall as the actual content (i.e. half-screen) but that would make it a bit strange for the user because it would be hard to tell apart the actual content from the modal view. But hey, it’s your app. You can do what you want. Another option is to set the background of this view black and partially transparent. That would look cool and show a nice smoky cover while we’re in modal mode… unless you’re mucking with color (like we are in this example) in which case it’s best to leave it fully transparent. Next throw the following code in the parent UIViewController. Load up the UIViewcontroller/UIView you just created and pass the view to this routine instead of calling the standard presentModalViewController method (substitute your application delegate for MyAppDelegate):

// Use this to show the modal view (pops-up from the bottom)
- (void) showModal:(UIView*) modalView {   UIWindow* mainWindow = (((MyAppDelegate*) [UIApplication sharedApplication].delegate).window);   CGPoint middleCenter =;   CGSize offSize = [UIScreen mainScreen].bounds.size;   CGPoint offScreenCenter = CGPointMake(offSize.width / 2.0, offSize.height * 1.5); = offScreenCenter; // we start off-screen   [mainWindow addSubview:modalView];    // Show it with a transition effect     [UIView beginAnimations:nil context:nil];   [UIView setAnimationDuration:0.7]; // animation duration in seconds = middleCenter;
[UIView commitAnimations]; }

What this does is add your view as a top-level above the main window, effectively rendering it modal. It also uses Core Animation to move the window from offscreen bottom up until it’s fully shown. You should adjust the timing to suit your view’s actual height. I’ve found that the taller the semi-modal view, the more time you should give it to become fully visible. Now let’s go through the hiding action. Note that we use the animation completion handler to do the actual removing of the item from the parent view and cleaning up. We also use the context parameter of the animation call (which was thoughtfully provided for exactly this sort of thing) to keep track of what view to clean up afterward:

// Use this to slide the semi-modal view back down. - (void) hideModal:(UIView*) modalView {   CGSize offSize = [UIScreen mainScreen].bounds.size;   CGPoint offScreenCenter = CGPointMake(offSize.width / 2.0, offSize.height * 1.5);    [UIView beginAnimations:nil context:modalView];   [UIView setAnimationDuration:0.7];   [UIView setAnimationDelegate:self];   [UIView setAnimationDidStopSelector:@selector(hideModalEnded:finished:context:)]; = offScreenCenter;   [UIView commitAnimations]; }  - (void) hideModalEnded:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context {   UIView* modalView = (UIView *)context; [modalView removeFromSuperview]; } 

[ Update: As noted in the comments, there was an extra release on modalView in hideModalEnded. This code was excerpted from a larger code-base and the release was left in inadvertently. The code listing here has been updated. Thanks for catching it, folks. ]

What I’m not showing you here is the way to trigger the show/hide action. That’s entirely up to you. In standard iPhone modal dialogs this is often a button in the toolbar or navigation bar. In the case of the semi-modal dialog, however, you have even more flexibility. Basically it comes down to the show/hide elements being:

  • Explicit: Provide an Accept or Cancel button on your view.
  • Implicit: You can simulate an action toolbar that shows and hides this way. Put a row of buttons on the view and wire it so tapping each one invokes hideModal before going on to the actual action.
  • Other: Tapping anywhere else on the screen dismisses the dialog. You can do this by placing a full-screen sized view (or custom transparent button) behind your modal dialog and wiring it so it a tap-down action dismisses the dialog . For best results, try making this full-screen view black and semi-transparent (e.g. opacity=0.2). This way the user’s main view darkens so they get a sense your modal dialog is in focus but they still get to see what’s behind.

Here’s a movie of the above semi-modal view in action. It lets the user select a color then confirm or cancel the action. The modal view in this case also has interactive controls on it. As the user changes color the background image changes in real-time so they can visualize what the end-result will be like. Once they’re done they can tap the checkbox or X/cancel buttons to make the modal go away.

The semi-modal dialog is a handy UI interaction component but it’s important to think about how to dismiss the dialog and what to allow in the rest of the visible region on the main window to avoid confusing the user. Also note that there are no restrictions on the shape or size of the overlay view as long as the background color is set to [UIColor clearColor]. You can use the same method for irregularly shaped pop-ups.

Go nuts and have fun.

[Update: Nathan in the comments below has posted some code on github. You may want to check it out. ]

Push Notification and Python (Django)

Posted by: Ramin on September 9, 2009

I’ve been trying to get the iPhone Push notification services introduced in OS 3.0 working with Python (specifically, Django). It took a while but I figured I’d post my notes so it’ll spare someone the suffering I had to go through.

Other attempts at this (apns-python-wrapper (aka APNSWrapper) and Lee Packham’s code) both use the standard ssl libraries which I couldn’t get to work under Snow Leopard and Python 2.6.

I eventually got it going with Django and pyOpenSSL libraries. The easiest way is to get the prebuilt pyOpenSSL binaries from eGenix. If the test server is running on Snow Leopard the Python 2.6 UCS2 version seems to work best.

The thing about pyOpenSSL is that it expects the certificate and private key to be in separate .PEM files so you have to export each one from KeyChain Access in .P12 format then convert them to .PEM from the command line. For the development key it’s easier to specify the password during export then strip it out on the command line. In production you may not want to do that.

   % openssl pkcs12 -clcerts -nokeys -out devcert.pem -in devcert.p12
   % openssl pkcs12 -nocerts -out devkey.pem -in devkeypw.p12
   % openssl rsa -in devkeypw.pem -out devkey.pem

Now copy devcert.pem and devkey.pem (with no password) into the server directory.

The following bit of code is in a file called and does the actual talking to the push server (I heavily edited out project-specific bits and standard exception and error-handling stuff. Hopefully didn’t bork it too badly 😉

Also, in this example the actual communication runs in a thread. In some cases it might make more sense to run it as a main routine:

import os, sys
import struct, binascii, ssl, datetime
import threading
import simplejson as json
from socket import socket
from OpenSSL import SSL
class PushSender(threading.Thread):	
def __init__(self, sandbox, token, message, badge, sound):
	super(PushSender, self).__init__()
    		self.token = token
    		self.sandbox = sandbox
    		self.message = message
    		self.badge = badge
    		self.sound = sound
    		self.ctx = SSL.Context(SSL.SSLv3_METHOD)
    		if sandbox:
    			self.apnHost = ""
    			self.ctx.use_certificate_file(os.path.join(PROJECT_ROOT, "devcert.pem"))
    			self.ctx.use_privatekey_file(os.path.join(PROJECT_ROOT, "devkey.pem"))
    			self.apnHost = ""
    			self.ctx.use_certificate_file(os.path.join(PROJECT_ROOT, "prodcert.pem"))
    			self.ctx.use_privatekey_file(os.path.join(PROJECT_ROOT, "prodcert.pem"))
    	def run(self):
    		payload = {}
    		aps = {}
    		if (self.message):
    			aps["alert"] = str(self.message)
    		if (self.badge):
    			aps["badge"] = self.badge
    		if (self.sound):
    			aps["sound"] = str(self.sound)
    		payload["aps"] = aps
    		token = binascii.unhexlify(self.token)
    		payloadstr = json.dumps(payload, separators=(',',':'))
    		payloadLen = len(payloadstr)
    		fmt = "!cH32sH%ds" % payloadLen
    		command = '\x00'
    		msg = struct.pack(fmt, command, 32, token, payloadLen, payloadstr)
    		sock = socket()
    		s = SSL.Connection(self.ctx, sock)
    		s.connect((self.apnHost, 2195))

[ PushSender source ]

To invoke it in a thread (the first param is True for sandbox and False for production server) from the main routine:

	from PushSender import PushSender
	pushsender = PushSender(True, token, pushmessage, pushbadge, pushsound)

On the phone the token returned by the didRegisterForRemoteNotificationsWithDeviceToken method is in the form <xxxxxxxx xxxxxxxx ...>. To pass it along to the server you have to strip out the <> and spaces. The unhexlify method then converts this string into a 32-byte hex binary value. The easiest way to strip out the extraneous stuff is to just do it on the client-side:

    NSString *deviceToken = [[[[tokenString description]
			stringByReplacingOccurrencesOfString:@"< " withString:@""] 
			stringByReplacingOccurrencesOfString:@">" withString:@""]  
			stringByReplacingOccurrencesOfString: @" " withString: @""];

One last thing: at least with the sandbox if the phone is running on WiFi sometimes push notices don’t come through. This may be due to router NAT or firewall configuration issues. One way to check is to go into XCode Organizer while the phone is tethered and run your app, then under the Organizer Console you can check for errors. To get around this you’ll want to turn off the WiFi on the phone and go with 3G. This usually makes push notices arrive as expected (and strangely enough the WiFi method goes back to working for a few minutes).

There’s more that needs to be done to make it production-ready but at least it’s good to know it’s doable:



Debugging peer-to-peer and wifi apps on the iPhone

Posted by: Ramin on June 18, 2009

If you’re developing an iPhone application that uses WiFi networking or the new Gaming Kit (Bluetooth) at some point you’ll want to test the code on two devices side-by-side. At this point you will realize that:

a) You can only run one instance of XCode on your machine at a time.

b) Debugging one device at a time is a royal PITA.

c) Your only option is to beg, borrow, or steal another Mac then install all of XCode and your code onto it just so you can do some debugging.

I’m here to tell you there’s a better way.

The solution is to use VMWare Fusion with Leopard or Snow Leopard server as a “guest OS.” (In VMWare-speak your regular machine is a host OS while each virtual OS instance running on it is a guest OS.)

The reason this works is because the latest version of VMWare allows you to run OS X Server as a guest OS on top of another OS X host OS. VMWare also allows you to assign specific USB devices to each VM instance so you can tell it that one iPhone/Touch belongs to the guest and the other to the host OS. Now I’ve only tried this with Snow Leopard Server so I’ll stick with that but VMWare says it can also install Leopard Server but I have’t tried that. Since Snow Leopard is still under NDA I’m not going to go into any specifics of the OS itself. Instead, I’ll show you how to set up VMWare so it can pull this off.

To start you’ll want the latest VMWare version (2.0.4 2.0.5 as of this writing). Earlier versions may not support OS X as a guest OS. To get access to the Snow Leopard releases you’ll need to be part of the Apple Mac Developer program. You’ll want the Server release. During WWDC 2009 some people were reporting having trouble installing Snow Leopard under VMWare from a disk image file so you might have to sacrifice a blank DVD and burn it to disc before installing it.

With the disc all you have to do is pop it in and it does the right thing. Or you can walk through and manually choose which versions you want to load.

Technically VMWare is only supposed to run Leopard/Snow Leopard Server which installs a lot of extra background services, etc. and needs a pretty hefty chunk of memory. If you Google around there are ways to patch the VMWare settings files to let it install Client. Far be it from me to suggest you do this, since it’s not certified and is not recommended for production use. All I’m saying is it might be less resource intensive and prevent your MacBook Pro from catching fire after the fans run on full-bore trying to cool down 100% loaded dual-core CPUs. But then again, YMMV.

So once you have VMWare and Leopard/Snow Leopard installed, you’ll want to install XCode (which comes on the OS install disk under “Extras,” or it can be downloaded separately from the Developer Connection website). Once that’s done you’ll also need the iPhone SDK. If you’re a member of the iPhone Developer Program (and really, who isn’t nowadays?) you’ll want to download and install the latest SDK (note that there are different downloads for Leopard and Snow Leopard).

Inside VMWare you’ll want to set up directory sharing. I won’t walk you through that here but if you have trouble getting the VMWare “folder-mapping” feature to work (like I did) one workaround is to turn on file-sharing in the host OS and mount the networked filesystem from the guest OS. If you do this, make sure you restrict access to only your own account on the shared volumes and turn it off for everyone else, otherwise all your pals at the coffee shop sitting on the WiFi and running Bonjour will have access to your source files.

Next you’ll want to end up with two separate projects, one for the host and the other for the guest OS. The reason for this is because each instance of XCode makes changes to the project settings each time you do a build. If you share the projects and load them from two XCode instances, you’ll end up with an endless litany of XCode warnings asking you if it should reload the project from disk. Save yourself a lot of headache. Just create separate projects but keep all your source and media files in the same shared folder. This way if you do actually make changes to the source code during debugging you only have to do it once from either side, otherwise it’s a nightmare keeping track of deltas.

(Handy tip: if you have dual monitors, install VMWare tools and put the guest OS on the second monitor then have it go full-screen. It’s like having two actual systems in one.)

So now comes the fun part: plugging in the actual devices. Make sure you’re not running XCode or any other app that accesses the USB devices behind the scenes. If you have iTunes set up to auto-run and sync when a device is plugged in you either haven’t done much real iPhone device debugging or you have a much higher tolerance for Annoyingly Intrusive Software. I turn off all auto-sync, auto-run, auto-whatever features that iTunes throws in to make itself the consumer-friendly app that it is. But that convenience gets in the way of debugging, so do yourself a favor and turn it all off. Manual sync mode is your friend.

iTunes also installs an iTunesHelper app that runs in the background. I personally take that out too by going into System Preferences > Accounts
then clicking on the “Login Items” tab button, finding “iTunesHelper” and hitting the ‘-‘ button (or delete) to take it out. The point is, if iTunes snags your USB port before VMWare gets to it you won’t be able to switch it over.

So now we have the two devices plugged in. Do NOT give in to temptation and start XCode just yet. In VMWare bring up the “Virtual Machine Library” which lists all your VM instances (if it’s not already showing, go under Windows > Virtual Machine Library). Select your Leopard/Snow Leopard instance then push the “Settings” button.

Now go into the USB devices section. Note that you can only make changes to the guest OS once it’s powered up and running. So if the guest OS isn’t already running, boot it up. You’ll be faced with a list of all the USB devices on your host machine, something like this:

Unfortunately VMWare doesn’t actually show the device names as assigned through iTunes so there’s no way to tell which device is which. If you have two iPhones plugged in they both show up as Apple iPhone. You can always test an iPhone against a 2G touch (the Touch shows up as Apple iPod). Then again, if both devices are running the same code it may not really matter.

Turn on the checkbox next to the device you want assigned to the guest OS. If it doesn’t stick then it’s likely you’ve got some other app locking up your USB ports. Go back and re-check (might have to do a clean reboot). I should note that this was the most frustrating part of the whole exercise. The trick that made it work for me was to make sure XCode is not running until AFTER you’ve done your USB port assignments.

Once it’s checked, *now* start up XCode on both sides. The host OS should be seeing one device and the guest OS the other. Verify by loading up the XCode Organizer and seeing that each device shows up with a little green dot next it. If you haven’t done it yet, you’ll want to tell the XCode Organizer that the devices are to be used for Development.

Getting excited? Almost there. Now choose iPhone Device from your XCode Active SDK pop-up.

Ready to hit Build and Run?

Not so fast.

Your iPhone development certificate is only installed on your host OS. The guest OS is a whole other machine and it needs to be set up as if it was a brand new machine. Fortunately, it’s fairly straightforward to get the keys moved over.

Launch the Keychain Access application (in Applications > Utilities) on your host OS. If you followed the iPhone SDK instructions and created a provisioning profile for your application on the iTunes Connect site, you should have a private key certificate installed in your keychain. If you’re like me and have done this a number of times, you’ll have lots of similar looking keys floating around. The trick is to look for the private key with your name and a drop-down disclosure arrow next to it. Open those up and verify that they say iPhone Developer and/or iPhone Distribution next to them. If you’ve followed Apple guidelines you should have one for development and another for app-store or ad-hoc distribution.

While you’re there, it’s a good time to make sure the expiration date is in the future. I got bit once and boy, was it a pain to diagnose. Stuff that was working one minute magically stopped the next. So stay on top of your certificate expiration dates. If the date is pretty close or already gone by go back to iPhone developer site and follow instructions to regenerate new keys, then install them and come back when you’re done.

Command-select all the private certificates you want moved and export the lot of them (File menu > Export Items…) Make sure they go out as .p12 (Personal Information Exchange) files. You will be prompted for passwords. Pick something pithy but memorable and save the exported file to a shared folder you can get at from the guest OS. While you’re at it, you may also want to move over your app’s provisioning profiles just in case you need it later.

Back in the guest OS, double-click the exported certificate file, enter the password, and install it in your keychain. You’ll probably have to restart XCode so it picks up the changes. To verify that it worked, bring up the XCode project in the guest OS, do a Get Info on the target and make sure the Code Signing Identity is selected and is the same as the private key you just installed.

So NOW you’re ready to go. Select iPhone Device from the Active SDK on both sides, hit Build and Run, go grab a cup of coffee or an adult beverage, and wait until both instances come up side-by-side.

So, yay!

That wasn’t too bad, was it?

A few final thoughts: I ended up running Snow Leopard as both host and guest OS since I wanted to run XCode 3.2 with the latest goodies on both sides. You’ll definitely want separate project files if you want to run Leopard in host and Snow Leopard in guest OS. At this point it’s not clear if app-store submissions can be built using unreleased versions of XCode. So you might want to check on the developer forums before doing the crazy thing I did and upgrading everything everywhere to the new shiny version.

Also, there’s no reason this shouldn’t work for three or more devices (for group peer-to-peer or mass WiFi testing) but you’ll need a beefy Mac with a lot of CPU and memory. You’ll also be needing a USB hub (I ended up with this Belkin Ultra Mini model based on advice from @schwa on Twitter) if you run short on USB ports. All it takes is another VMWare instance and assigning the right device to the right OS instance. Lather, rinse, repeat.

Happy debugging!

Update: Make sure you read VMWare update release notes. In the latest release there are two known issues that directly impact this way of using VMWare:

  • When being installed on a Mac running Mac OS X 10.6 (Snow Leopard), VMware Fusion does not install MacFUSE

    MacFUSE might cause the installer to fail or become non responsive, so the VMware Fusion installation process does not install it by default on a Mac with OS X 10.6.

  • Selecting the Sleep option on a Mac OS X Server guest operating system causes it to stop responding
    The default setting for Mac OS X Server is for it to never sleep. However, if you change the setting or use Apple > Sleep, the virtual machine might stop responding.
    Workaround: Shut down the virtual machine and restart it, and make sure that in the Energy Saver window of Apple > System Preferences, the Put the computer to sleep when it is inactive for: slider is set to Never. Do not use Apple > Sleep.

You’ll definitely want to turn off Sleep mode as soon as you’ve installed the guest OS and before you walk away from the system for an extended length of time otherwise you’ll have to hard-reboot the VM instance. I even turn off the screen-saver. If the system is idle for any length of time the host OS should be the one doing the sleeping and screen blanking.

The first issue is also easily solved. You can manually download and install MacFUSE. It allows you to use not only third-party file systems on top of MacOS, but file systems on local disk, across the network etc. There are some issues with folder sharing across guest/host applications that clean install of MacFUSE might clear up.

On Tweaking and Sucking

Posted by: Ramin on May 25, 2009

I feel like things as they are have about as much awesomeness as they’re capable of having, and you can’t imbue awesomeness into something that actually sucks. And in its way, something that sucks full-bore sucking at me is a kind of honorable experience–it’s an honorable exchange.

Steve Albini — indie music producer interviewed on public radio’s The Sound of Young America.