Talk Funnel

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 Messages.app 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.

Word came today that Apple’s WorldWide Developer Conference is going to be running from June 8-12 2009 in San Francisco.

Since Apple’s no longer going to be participating in MacWorld this is one of the few public conferences where Apple and its partners can make public product announcements. So now’s a good time to start floating outlandish rumors
predictions as to what’s going to be announced.

Since Apple already announced its intention to release iPhone 3.0 software around that time, a lot of products will be taking advantage of those features. One of them was access to the external USB port. The announcement demo featured a heart-monitor. My prediction is it will be totally upstaged by one of these:

One of the loudest complaints about the iPhone AppStore has been the lack of support for eval or demo applications. In the desktop world users can often download an application and use it for a period of time before deciding whether it’s worth paying for. But in the iPhone AppStore universe (where all transactions occur) there is no such support. Developers are then faced with the option of offering a lite version for free (or inexpensively) and a full version of their apps. The problem is that this still doesn’t allow the end-user to test out the full app and then choose to buy it if it fits their needs. And switching from a free to a full app involves installing an entirely independent application.

What we really need is a way to upgrade an eval app to the full version once the user decides the app is worth paying for.

Yesterday Apple publicly announced the developer release of iPhone 3.0 software (it won’t be publicly released until this Summer). To the dismay of many developers, there was — once again — no mention of support for eval applications among the 100 new features and “1000 new APIs.” So again, we are left without the option of letting users download an app, take it for a test run and then pay for it.

Or are we?

One of the features announced publicly was support for In App Purchases. This was presented as a way for users to obtain add-on levels or objects directly within games. The transaction (or more precisely, micro-transaction) still goes through the AppStore and gets charged to the same account. Despite public detractions I belive this is a Good Thing — especially since the feature can be used to legitimately support eval applications, even if the AppStore doesn’t officially support it yet.

Here’s how:

• Developer offers application for free on the app-store. This is a fully functional version (i.e. not lite or crippleware).
• User downloads and runs the application and is informed that the application is in eval mode and will stop working after a period of time.
• After the eval period (say, 1-4 weeks) the application puts up a notice indicating the eval period has expired. It can either stop working or drop into a degraded mode.
• At this point the user is given the option of performing an In App purchase of the full application.
• If user accepts, the application contacts the AppStore and purchases the add-on — which would be priced at what the full-price of the App would otherwise be. Once completed, the app downloads an add-on key indicating the app has been purchased.
• The presence of add-on indicates that the full app has been purchased and the timeout is taken out. All the application has to do each time it is launched is to look for the presence of this add-on.
• Everyone’s happy.

There’s a key assumption here — that the AppStore keeps track of already purchased In App purchases the same way it does with full applications today. In other words, if the user tries to re-download an In App purchase that they’ve already purchased with the same iTunes account, they shouldn’t be charged twice. If a user deletes the app or moves to a new phone, all they have to do is download the free version of the app, perform another In App purchase (for free this time) and off they go.

However, if this assumption is not true and In App purchases are tracked separately than full applications (or the application itself is responsible for keeping track of those transactions) then the developer will have to implement a way to track In App purchases that works across multiple app installs — most likely a simple web-server to keep track of eval vs. purchased apps. Let’s hope it doesn’t come to that (the documentation on the Store Kit is not out as of this writing and even if it was, developers under NDA won’t be able to talk about it publicly until the public release of the 3.0 software).

There are some other issues that need to be hashed out, mainly what happens if unscrupulous third-parties find out what this add-on looks like and make it available for free download? The iPhone application sandbox makes it a non-issue since only the application itself is allowed to write to its Documents directory or modify its user settings — unless the phone has been jailbroken, in which case the concerned developer may want to support more complex security (like cryptographic signing) for the add-on. Given that the AppStore DRM appears to be compromised using this technique does not significantly increase the risk of software piracy.

Another potential issue is the user who downloads the fully functional eval version, uses it for the full eval period, then deletes it, re-download and installs it so they can get another free eval period. If this is an area of concern, it can be handled through a simple web-service that keeps track of how many times the same user has installed an app. Personally, I don’t think it’s worth the hassle given that deleting an app also gets rid of all user-generated data. But that’s me.

Note also that when I’m talking about downlaoding something, I don’t mean literally downloading a chunk of code, but some sort of token that takes away the eval time limit. The whole operation can be performed very quickly once the In App transaction is completed.

I firmly believe having support for eval apps is critical for medium to high-priced applications to flourish on the AppStore. A user will hesitate to fork out a high price for a full-featured app without having the option to kick the tires beforehand. This method can easily solve the problem and let developers do eval apps as soon as the 3.0 software is officially released.

Update: Apple has since announced that free apps can not use StoreKit. This is to avoid a potential bait-and-switch situation where the consumer downloads what they think is a free app and then get hit with a fee. However, I think it’s a misguided policy. A developer who does that will quickly get down-reviewed (if they even make it out of the app-review chute). A more likely scenario would be to allow users to use an app for a limited period of time, but give them the option to unlock the app for continued use.

Another more fundamental issue, however, is whether app developers even want an eval feature. I’ve heard from several Android developers that the Android store return policy has severely impacted sales of their apps. Their argument is that returns should be based on faulty apps, not because someone found their game too hard. Presumably, enabling eval apps will cut down on a lot of impulse-then-discard purchases that go on today.

Certainly a topic worthy of further discussion.

I spent all yesterday at Apple’s first iPhone Tech Talk in San Francisco (technically, Paris was first because of time differences, but we won’t quibble). After seeing the schedule of events (and having attended WWDC) my expectations for getting new technical information were pretty low.

Boy, was I wrong.

The talk itself was under NDA so I won’t go into details. But I’ll point at a couple of items in current examples and documentation that everyone should be aware of:

• If your app is using audio in any way, you’ll want to make sure you’ve read and understood the “Audio Sessions: Cooperating with Core Audio” section of the “Core Audio Overview” document (it’s part of your help document set in the SDK).

  Of special importance is making sure you declare the proper AudioSessionCategory for your app. Not doing it means that if your app uses sound (input or output) and gets interrupted — by an incoming phone call, or even by the user plugging and unplugging headphones — your app’s sound may not continue playing properly. There’s some example code in the SpeakHere example to help point the way.

  Here, by the way is what the documentation says:
  

  Ignoring Audio Session Services will not prevent your application from running, but your app may not behave the way you want it to. Never ship an iPhone or iPod touch application that uses audio without using this interface.

  You’ve been warned.

• If you’re using the accelerometer, you’ve probably seen the low-pass filter code in the docs and examples. The point of the filter is to smooth the effect of motion ‘jitter.’
  
  The thing is, the basic low-pass filter formula is — to put it mildly — non-functional (aka brain-dead). Again, I can’t talk about the specifics, but the presenter had graphs that showed how bad that formula behaves.

  Actual color graphs, I tell you!!!

  If you manage to get your hands on a sample iPhone Apple application called Touch Fighter — you’ll want to use the smoothing function there (the app was handed out in WWDC and isn’t part of the standard SDK example set).

  If you can’t find it, I suggest looking around for source code that handles the Wii remote (they have to deal with similar issues). At some point, I might post a more detailed technical article on this.

• Gesture management is still something that Apple leaves to individual developers, instead of including it in the SDK. I have a ’swipe’ detection library (but it’s only for one-finger swipes, not multi-touch). If there’s demand for it, I’ll post it up.

  But really, this should be something supported in the OS.

Most of the TechTalks are full now. If you happen to have gotten accepted, don’t skip them. If not, get on the waiting list. It’s worth it. The sessions on game development and performance tuning are massive info-dumps. Might want to take a lot of notes.

P.S. That mod-squad picture on the web site (excerpted above) features actual Apple evangelism group members strutting their stuff

When I upgraded my MacBook Pro to Leopard last October, one of the first things I checked was whether the built-in firewall was running or not. To my abject horror, I found out that a) it wasn’t and b) it wasn’t really doing what I expected it to do, namely, keep incoming port-scanners out. Subsequent in-depth security analyses didn’t exactly raise my confidence much.

Since I do most of my development work on my laptop and so much of it entails running various types of servers locally, I set out to find something that actually kept snoopers out. A quick search led me to Intego Software and their NetBarrier product (Symantec’s Norton products don’t run native on the Intel CPU). There are people out there who don’t like Intego and their offerings, especially with the ‘hidden’ annual subscription fees associated with the software (now this isn’t unusual in the Windows world, but it’s something the folks at Intego should mention right upfront.) But I haven’t had any bad experiences with them. Besides, choices were few and I found a deal for under $60.

To be clear, most people at home connect to the Internet through a router that offers them NAT services which effectively blocks incoming connections. For those situations, a software firewall is overkill. But if like me, you spend a lot of time at public WiFi hotspots like coffee shops or away from known, trusted routers, then you’ll want to run a firewall to keep the legions of port-scanners out there at-bay. If you think you’re unlikely to be a victim of port-scanning, think again. Last time I set up a web-server with a static IP directly connected to the net, it took less than 15 minutes from the time the ISP turned on the tap to when the first port-scans came in. By the time I turned the server off a month later, the web-server log-file was chock-a-block full of known exploits and bizarre attempts at trying to break through — most of them through overseas IP sources and zombies.

But I digress.

Read the rest of this entry »