We're hours away from the 2020 WWDC Keynote. Over the last week there have been tonnes of conversations about Apple's policies and while I'm on the side of change, this post isn't about that.

I've been compiling this list of security features that iOS needs for probably more than 5 years now, and every year around WWDC time I plan to publish it, and never actually get to it. Today, that's changing.

Here's my list of security features I'd love to see in iOS sooner rather than later.

1. Increased user control over device locking

There are multiple features that need to be added here.

a) A system level method that allows the user to lock the device underneath the currently open app. This means, keep the current app open and accessible, but the rest of the device is locked. You can't swipe to another app, you can't go back to the home screen, you can't tap on a notification and have it switch apps, in fact, if you have content in notifications hidden while the device is locked, incoming notifications in this mode would also be hidden.

Why add this feature? Because many apps used today require the app to be open for an extended period of time, so using those apps increases the risk for the user.

Examples:

Games (Pokemon Go): You need to keep your device open while you're walking around looking for Pokemon. If someone jumps you and steals your phone, it's unlocked and they have full access, just because you were playing a game. Of course, other games require you to keep the phone on because you're actively using the screen.

Sleep Trackers: There are apps that you leave open and running next to your bed while you sleep. They listen for your movements, snoring etc, to track your sleep. Doing this however leaves your phone unlocked and exposed for hours at a time while you're asleep. Ignoring people in your home that may exploit this situation, there's always the possibility of a thief (or even law enforcement) breaking in.

Video apps (Netflix etc): Want to watch the latest movie on your phone? That will keep your device unlocked for around 2 hours. Same risks apply, you could fall asleep, have someone grab the phone out of your hands etc.

Grocery Lists: In the age of COVID when we're all wearing face masks whenever we leave our homes, unlocking your phone becomes extra tedious. It's not unusual to disable phone locking while grocery shopping so you can constantly refer to your list without entering your passcode hundreds of times.

COVID Bluetooth trackers: Since Apple has blocked background Bluetooth access, several companies are releasing COVID Contact Tracing apps that use Bluetooth, but require the app to run in the foreground. Again, a serious security risk.

Allowing the user to lock the device underneath the current app solves these problems. The user can keep using the app in question, without risking the security of the rest of the device. This can be done with a gesture each time to trigger that you want to lock the device, or it could even use a timer that just auto locks the device under any app that is in the foreground for a specified time.

b) Allow a user to specify certain apps that can be used even if the device is locked. The UI for this feature would likely add those app icons to the lock screen so you can just jump right into them, locked or not. Same cases above are solved.

c) Use the Apple Watch to automatically lock your phone. If your phone moves too far away from your watch, auto-lock it. This handles cases where someone grabs the phone from your hand, and also cases where you leave the phone at your desk when you go to the washroom or something (back in the days when people went to offices). A bonus would be if you could disable Touch/Face ID via your watch.

If I can only have one of these security improvements this year, please let it be this one.

2. Improve the 2FA used on our Apple accounts

Apple's 2FA is one of the worst available. It's only better than systems that still use SMS for the second factor.

Ideally they allow you to store the key so you can use any standard 2FA app. At a minimum, they need to fix the geo-location on alerts. Telling me someone 150 kms away is trying to log into my account when it's really me on another device right next to me is pretty pointless. At least show me the IP address that is being used, and if it happens to be the same IP as the device you're showing me the alert on, tell me that too.

3. Secure the password dialog boxes used for our Apple accounts

The system can ask you for your iTunes/iCloud credentials at any time. This can happen while you're in the settings, the App Store, or even a random third party app. And the dialog is a standard dialog that any app can present. Most users use the same email address for their Apple ID as they do to log into apps, web sites, etc. This allows for unscrupulous apps to phish the user and trick them into giving up their vital Apple account password.

It is possible for advanced users to distinguish the difference between a dialog Apple is presenting and one presented by an app (swiping up on a system dialog is disabled), but try explaining that to normal users, never mind actually expecting them to test every time they're presented with a password request.

A simple solution would be to have a uniquely customized dialog box when the system is asking for your credentials. This unique dialog would not only include the email address of the account in question, but would display a secret image or pattern that was pre-selected by the user when they created their Apple account. This would need to be added to existing accounts during their next upgrade process.

4. Multiple users (including a guest account) on iOS

This is a simple one, and pretty self explanatory. Often someone wants to 'just borrow your phone for a sec'. A guest account with access to non-sensitive apps would make it easier and less risky to help someone out.

5. Improvements to Touch/Face ID

Add other options to the "Require Passcode" other than 'Immediately' when using Touch or Face ID. I've been asking for this change since Touch ID debuted, mainly because when debugging in Xcode, it's really annoying having to constantly unlock the phone while you're trying to install the newest build. You'd unlock the phone, build & run, then the phone would lock before the build started and you'd have to unlock it again.

With COVID, this is an important feature for people that aren't developers. See above for the grocery list scenario. When wearing your mask, being able to enter your password only once every 5-15 minutes would be a huge benefit.

6. Atomic app upgrades

When apps upgrade, it should be an atomic process. I've seen cases where app A is installed and working, then it upgrades via the App Store, but the network drops during the upgrade process. The app becomes unusable now. You can no longer access the data until the system completes the upgrade process.

Granted, listing this as a security fix is a bit of a stretch. But one of the times I saw it happen, it was 1Password that became unusable. I consider not having access to my passwords a security issue.

7. Medical ID

Users should be able to add photos to their Medical ID profile. This could include QR codes, scans of their hospital cards, insurance information, scans of medical history, prescriptions etc.

Acknowledgements:

My thanks to Markus Winkler at Unsplash for providing the photo used as the sample security image in the updated password dialog box.

This was my first WWDC, but it certainly won't be my last. It was a great experience and I'm going to try and share some of the things I learned over the last week. Nothing that's covered by the NDA of course.

1) It was great to finally meet some of the big wigs in the community. Drinking beer with Jeff LaMarche and the other MartianCraft guys. Hanging out with the Empirical Development guys that I've been working with for most of the last year was awesome. Getting to pitch Party Doodles to Eli Hodapp (of Touch Arcade) and Victor Agreda, Jr of (TUAW) in person was amazing. I'm sure it helped that Apple basically used Party Doodles as an example of how to do an AirPlay game correctly.

2) Probably the biggest shock to my system was the amount of walking involved. As someone who normally sits at a desk for 12+ hours a day, it was a major change to walk back and forth from my hotel 2 or 3 times each day. Why 2 or 3 times you ask, depending on whether or not I took my laptop to the sessions and wanted to drop it off at my hotel before dinner/socializing etc, or based on meetings with various people I had scheduled between sessions.

3) In most cases, you do not need to take your laptop with you to the sessions or labs. I had a completely incorrect assumption of what the labs were. Labs should be considered more like Q&A sessions with Apple engineers. They are not planned tutorials or anything scripted. They're just a chance to ask a question, sometimes with someone who may have helped build the system you have a question about. The only time having your laptop with you is probably if you need to show an engineer your code during your Q&A (lab) session.

4) For the labs, my own experience was pretty dismal in this regard. I had a few questions to ask about various topics, and each time, the engineer(s) I was talking to had no more information to provide on the issues. That being said, I heard of some people that had much more successful visits to the labs.

5) The actual sessions where amazing. Some covered brand new information about iOS 6 or Mountain Lion, while others covered older information that you might have missed. Sometimes you see something presented that's been available for a while that you just hadn't seen and you think "this will save me hours". When the session videos are released, make sure you watch as many as you can. Even if you think you already know about a topic. There are always extra little tips that are invaluable.

6) When you attend a session in person, please use some common decency and follow these four rules:

1. When sitting down, move to the center of the row, don't 'end cap' the row by sitting in the first seat. Most sessions fill the entire room and when everyone has to fill in rows by jumping over a person sitting in the first seat, it's pretty annoying.
2. Wait until the speaker has finished talking before running out to the next session. We all have to get to the next session at the same time, give the speaker the respect they deserve by letting them finish.
3. Do not use a MiFi device. They jam the provided WiFi and in some cases prevented even the presenters from being able to demonstrate what they had planned.
4. Take your trash with you. If you bring in a drink, lunch etc, just take the garbage with you when you leave and drop it in the garbage bin or recycling etc. I think they teach this in kindergarten but it appears some people missed that day.

7) Related to #2 above, the choice of hotel is important. The closer the better (or at least the less walking you have to do). But there are other issues. I only have experience with the one I stayed at this year, Parc 55 Wyndham, but I'm pretty sure I won't be staying there again next year. The room was nice, clean etc, most of the staff were nice and helpful. My issues with the hotel were

1. the network is awful. Wifi or wired, it wasn't strong enough to keep iChat connections alive. And they charge $15/day ($50/week).
2. the included breakfast only includes pastries, you can add eggs and bacon for $25!
3. the elevators are extremely slow, taking up to 10 minutes to go up and down.
4. the TVs are locked down and prevent you from adding your own input, no connecting Apple TV or your laptop for example. That made testing some changes to Party Doodles impossible.

8) Since I'm Canadian and our roaming fees are insane, I wanted to pick up a local SIM card in order to be able to use data whenever I needed. I have an unlocked phone so it should have been easy. Eventually I went AT&T, $50 for unlimited voice and text, and $25 for 1G that they said wouldn't work on an iPhone and that they wouldn't refund the cost if I couldn't get it to work. After putting in the SIM card, it took all of about 30 seconds to switch the APN using the site: http://www.unlockit.co.nz/. The AT&T network has been great the whole week (Keynote excluded, but nothing was working there).

9) J.J. Abrams. Wow. He was a guest speaker for the Friday lunch session. And boy was his talk amazing. For one, he was by far the most entertaining speaker of the week, granted his content makes it easier, blowing up stuff is more exciting by itself than NSManagedObjects being accessed by the wrong NSManagedObjectContext. But his way of presenting was great, it almost felt like it was just me and J.J. in the room and he was telling me stories from his life. It was very interesting to hear how certain ideas/shows came to be due to other events in his life, in much the same way we move from app to app where the first app may inspire the idea for the second app. I'd love to go into more detail here, but it seems even this talk is covered by the NDA. J.J., if you're reading this (maybe Google Alerts brought you here), I just want to say thanks for the awesome and inspiring presentation.

10) One last point. Since it was my first WWDC, I wasn't sure when I should be here, so booked my flight for Saturday to Sunday. Getting here on Saturday worked out well, gave me some time to get to know the area and meet up with people for drinks etc. But next year I'll leave Friday night or Saturday morning. There wasn't much happening on Saturday or Sunday as most people have already left.

I'd say WWDC (I'm not yet cool enough to be able to call it "dubdub") was a great success this year. I can't wait for next WWDC 2013! It'll sell out super fast again next year, so be prepared...

If you haven't already, please download my free game Party Doodles, like us on Facebook, and if you like to hear me ramble, follow me on Twitter.

Today I'm going to cover some useful tips and tricks. These are presented in no particular order, and are pretty much unrelated to each other. Hopefully you'll find some, or all of them useful.

1. Regarding the upcoming iPad 2

Reports are starting to surface that the next version of the iPad will support a retina type display. Apple will no doubt repeat what they did with the iPhone 4 and double the resolution (4 times the number of pixels). This makes it easy to support old apps on the new device by employing pixel doubling.

But, you can start preparing for this now! For every iPad image you use, include a higher resolution (double sized) image with the @2x suffix. And for icons, include a 144x144 (double 72x72) icon. I've included a 144x144 icon in all my iPad apps since the iPhone 4 was announced, betting on Apple doubling the iPad resolution. It's cheap to do, and if the predictions are wrong, there's no harm in having an unused icon.

As a sub tip, you should include the following sizes for your icons: 144x144, 114x114, 72x72, 58x58, 57x57, 50x50, 29x29

2. self.var vs var

In your classes, when use the following syntax:

DWClass.h

@interface DWClass : NSObject {
    NSObject *myObject;
}

@property (nonatomic, retain) NSObject *myObject;

DWClass.m

@synthesize myObject;

You're telling the compiler that your new class DWClass will have a property called myObject, and that it should create setMyObject (setter) and myObject (getter) methods to access that property. And that those methods should handle your retain/release cycles for you. Any other objects that need to interact with your myObject property, will do so by like this:

dwClass.myObject // (assuming dwClass is an instance of DWClass)

And this will actually call the appropriate setter/getter for the myObject property, which in turn interacts with the myObject instance variable of the dwClass.

Inside the DWClass however, you can access the property like this:

self.myObject

And the same setter/getter methods are used.

Inside the DWClass, you can also access the myObject instance variable directly just by referencing it. DO NOT do this. If you do that, you're not using the setter/getter methods, which means you're not automatically handling the retain/release calls. This is a surefire way to create hard to find bugs in your code. Plus, there are other problems with doing this. If down the road, you need to do something special whenever that property is accessed or updated, so you ditch the @synthesize and create your own setter/getter methods, you're now going to miss even more than the retain/release calls, you're going to miss whatever else you've added.

This entire tip also applies to non-object properties. Even if you're using a standard int as a property, always use the self.variable syntax to access it. It's just good practice and will save you headaches down the road.

3. Keeping your secrets, secret

Often when you're accessing other services, Twitter, Dropbox, your own servers etc, you may need to store passwords, API keys, etc in your code. It's dead easy to just have a constant like this: @"MySuperSecretKey" and be done with it. If you do that though, you may as well post the secret on your web site for all to see. Since, it's trivial for a bad guy to extract your secret from the compiled code they download from the App Store after your release. This is a bad thing. In the case of Twitter for example, some spammer could put your secret key into a rogue app that spam blasts users. Every one of those tweets will say it was sent by your app, and your legit app will be blocked pretty quickly. Your users will be locked out until you submit a fix and have it approved by Apple, say goodbye to two weeks of sales, not to mention, all the bad reviews you'll receive for selling a non-functioning app.

So, keep your secrets secret, use some encryption inside of your app to encrypt your keys etc. It doesn't have to be complex as the bad guy usually just looks for low hanging fruit (unless they are specifically targeting you). You can use one of the many encryption libraries available, or even roll your own if you're so inclined.

4. Ensure the App Store knows you support multiple languages when you do so

This tip comes from a mistake I made in version 1.0 of the Cruze app. The app supported English and French from the get go, but it was done by detecting the language of the user via code and loading the correct set of files for the primary language. This worked great and was way less work than using Apple's recommended method of localization for every nib etc.

One problem though, once the app was released to the store, the only supported language listed in iTunes was English. Because I used my own language detection iTunes Connect didn't detect French. I fixed this in 1.5 by using Apple's localization on a small dummy text file. One that I don't actually use for anything in the app, but that is enough to trigger the language detection tools Apple uses.

Update: see Ovogame's comment below for an even better way to fix this issue.

5. AppName_Prefix.pch

There's a file in your XCode project named AppName_Prefix.pch (where AppName, is your app's name). This file is included at the top of every source file in your project. It's a great place for you to store any constants you need across your app.

6. A Better NSLog()

A common method of debugging is to add NSLog() calls throughout your code. The messages are echoed to the screen as the code runs and you can see what's happening, giving you hints as to what's causing bugs. When you're finished however, and you want to do your final build, all of those NSLog() calls remain in your final build and all of those strings are available for anyone looking through your binaries to see. Who knows what secrets you might disclose.

Instead of using NSLog(), I use DebugLog(). This is a tweak of a function I’ve seen others use, based on the answer here: http://stackoverflow.com/questions/300673/is-it-true-that-one-should-not-use-nslog-on-production-code.

Add this to your AppName_Prefix.pch file:

#ifndef DebugLog
#ifdef DEBUG
#define DebugLog( s, ... ) NSLog( @"<%p %@:(%d)> %@", self, \
	[[NSString stringWithUTF8String:__FUNCTION__] lastPathComponent], __LINE__, \
	[NSString stringWithFormat:(s), ##__VA_ARGS__] )
#else
#define DebugLog( s, ... )
#endif // DEBUG
#endif // DebugLog

Now, replace all of your NSLog() debugging statements with DebugLog(), and define DEBUG in your debug configuration (sub tip 2: go to your Project Info, Debug configuration, search for Preprocessor Macros, add DEBUG).

After this, use DebugLog() all you like, and the strings are skipped over in your Release and Distribution builds. You also have the added bonus of having the function name and line number included with all debug statements now, making it clear what's generating the messages.

7. *.dSYM files

Whenever you build your app, XCode will output the *.app files, as well as a *.dSYM file. For Debug and Release builds, you can just toss/ignore the *.dSYM file. But for your distribution build, that you're going to submit to the App Store, make sure you keep the .dSYM file. You'll need this later, to analyze crash reports. I'll go into more detail on this in a later post, just know you need to keep the files. For the impatient, you can read more on this here: http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/

8. Push Notification Certificates

If you have an app that uses push notifications, you need to generate a certificate with Apple, one of the first steps, is to create a Certificate Request file (CertificateSigningRequest.certSigningRequest), that you send to Apple. Keep this file. When your certificate expires, you'll need to request a new one. You can reuse the same Certificate Request file and skip the first few steps.

9. [object release]; object = nil;

With NSObjects, when you're done with them, you call release to reduce the retain count and let the system know you no longer need it. When that retain count hits 0, the system free's the object and releases the memory allocated back for use later.

It is common practice, to set the object to nil after you call release. This prevents a possible crash later, if you attempt to call a method on an object that has been freed. That's because if you try to call a method on a nil object, the system just ignores it, no error, all is good (or is it). If you don't set the object to nil, then it will still point to the memory address that was allocated for that object. There's a chance that object is still there (if something else was using it and increased the retain count for example). In that case, calling a method on that released object, will still work. But if that memory had actually been released calling the method would cause a crash.

This is why developers often set the object to nil, to prevent that crash in the case of a bug. But, this doesn't fix the bug, it just hides it from you. So, I subscribe to the second school of thought you shouldn't set the object to nil. If you have a bug, let the app crash while you're developing and you'll be able to find and fix that bug. When you no longer have any crashes, you'll know you're (closer to being) bug free, and that you haven't just masked your bugs.

Apple is making fantastic progress with iOS. They continue to release firmware updates and betas at a frequent pace, and with each new release, developers must download and install a new version of XCode compatible with the new firmware. Managing the various versions and their associated firmwares can be a challenge. In this article I'm going to give you a couple of tips that will hopefully help.

It's not uncommon for developers to have multiple versions of XCode installed on the same system in order to support development/testing across a wide range of devices and firmware versions. XCode by default installs in /Developer, and it is common practice to install the latest beta version in /DeveloperBeta. Those testing XCode4 know its default install folder is /XCode4. Personally I found this to be messy and inadequate.

My preferred setup now is to create a directory /XCode and install each version of XCode underneath using the version info as it's base folder name. Currently this looks like this:

/XCode/3.2.3_4.0.2
/XCode/3.2.4_4.1b3
/XCode/xcode4_dp2

When installing XCode in this fashion, you’ll find that in some cases, you won’t be able to install/debug a build on one of your devices because of a mismatch in firmware versions. For example, the XCode 4 Developer Preview 2 was released before firmwares 4.0.2 for iPhone and 3.2.2 for iPad. So if you’ve updated your devices to those firmwares, you’re now unable to use XCode 4 to directly install or debug.

There is a simple fix however. You just need to create symlinks from one version of XCode to another. Assuming you’re using a layout similar to what I’ve detailed above. If you look under /XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport you’ll see folders for each version of iOS that you can install/debug on. 3.2.2 and 4.0.2 are obviously missing. If you’ve installed the latest version of XCode 3 with support for those versions, you can make XCode 4 work with them.

In terminal, issue the following commands to create the required symlinks:

ln -s /XCode/3.2.3_4.0.2/Platforms/iPhoneOS.platform/DeviceSupport/4.0.2 \
	/XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport
ln -s /XCode/3.2.3_4.0.2/Platforms/iPhoneOS.platform/DeviceSupport/3.2.2 \
	/XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport

Similarly, If you’re using the 4.1 beta 3 firmware on your iPhone, you’ll need XCode 3.2.4_4.1b3 installed, and can then enable support for that firmware version in XCode4 also:

ln -s /XCode/3.2.4_4.1b3/Platforms/iPhoneOS.platform/DeviceSupport/4.1\ \(8B5097d\) \
	/XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport

If you have your XCode versions installed under a different directory structure (/Develper, /DeveloperBeta, and /XCode4 etc), you’ll just need to tweak the above lines to point to the correct folders.

A similar trick can be used to allow you to use a base SDK of 3.1.3 or earlier, which is no longer included in the latest versions of XCode. Just create links under the /XCode/Platforms/iPhoneOS.platform/Developer/SDKs to an older XCode that does include support for the SDK you need.

If you have any tips to improve upon this, see an error in what I’ve described, or otherwise have anything else to contribute, please let me know.

Everybody else seems to have a blog, so I suppose Cerebral Gardens ought to have one too. This will be written by me, Dave Wood, the founder and developer.

The issue that has compelled me to finally write something is the whole Tweetie upgrade pricing issue. First, I want to say that I always try to look at an issue from every side, though I'm not always successful at that. In this case it's pretty easy, since I'm both a developer and a user. Next, I'll admit that while I did buy Tweetie v1 for iPhone, I barely use it. I use Tweetdeck most of the time because of it's quick account changes. And Twitterific the rest of the time. Bought Tweetie just because it worked during the twitpocalypse. I do use Tweetie on my Mac exclusively (with the ads 'cause I like the ads, very relevant to me).

So, the issue with Tweetie v2 being a fully new version with no upgrade path is a tough one. Largely because developer’s choices are limited due to some of the restrictions imposed by the App Store. Enough people are writing about how to fix the store, so I'm going to present options that may work with the current setup of the store.

There are two main problems to deal with here (again, not counting the App Store issues). 1. Users expectations for free updates. 2. Developers needs for a sustainable business.

Regarding users expectations for free upgrades: I believe there should be an expectation for free upgrades for some length of time whenever someone buys software. That time is up for discussion. With a $1500+ Adobe Suite purchase or even Apples $69 iWork product, I believe that time period should be at least a year. With a $3 app, perhaps it should only be 30 days. Although I believe current users are expecting longer. Anyone expecting, or offering, lifetime updates is insane. That's obviously not sustainable.

But the expectations do exist; whether or not they should. Developers (myself included) need to start setting customer expectations to match our plans. Stating what the upgrade path will be in our app description for instance. Just stating something like 'free upgrades for 30 days' etc. As I type that I have to laugh. With a 14-20 day review process 30 days doesn’t seem like enough. 3 months perhaps.

John Gruber of Daring Fireball fame (whom I read religiously) compared buying a $3 app to a $3 cup of coffee. I don’t believe this is a fair comparison. The only thing they have in common is their price. A cup of coffee is a physical item, actual water, coffee beans, cream and sugar maybe, as well as a paper cup, and a plastic top. A person has to physically take your order, prepare the coffee to your taste, and hand it to you. The whole process takes a minute or so of someone’s day. If 1000 coffee’s are ordered at the same time, it takes a lot of people to serve them up in the time expected by the customer. Compare this to apps. There’s nothing physical with an app, not even a disc with iPhone apps. Once the app is made (and of course there is a cost there), it doesn’t cost much more per app ordered. It costs the developer (almost) the same to develop the app whether it ends up selling 10 copies, or 10 million copies. A closer comparison would be comparing apps to songs. We pay about $1.29 per song now. Imagine the uproar if songs were $3 each. Heck, I think $1.29 is expensive, but I pay it.

Continuing to compare to music, consumer’s expectations have been set; people buy a song or CD and they’re done. They don’t expect to get the same song again in a new format if it comes out; people joke about how many times they’ve bought the White album. They don’t expect to get an extended, or remixed version of the song for free if one comes out. The point here is that expectations of users can be set to be very low.

Perhaps this is what Atebits is starting to do. They’re reducing the expectations of their users, drastically. Possibly too fast, hence the uproar.

I've read that Atebits has said they would like to offer an upgrade path that gives current users a discount, but that it's not an option with the App Store. Here's one way it can be done. (This isn't pretty and I wouldn't recommend anyone else do this; further below is an option that could work for the rest of us, with time to plan).

Set Tweetie v1 to $999. No sane person would buy it at that price. If they do, Apple will refund it, (and hopefully not ding you the full refund price as indicated in the dev contracts). Then submit v2 as two apps, an update for v1 users, and a new app for $3 with text in the description to set the users expectations correctly. V1 users get the update they expected and also have their expectations for future updates set to nil. When v3 is ready, v1 and v2 are removed from sa le, v3 is submitted as a new app.

Regarding problem 2, the sustainable business: obviously developers have to be paid for their work, and continue to be paid for building upon that work. I’m going to assume that the incredibly low app prices aren’t going away; even if most developers raise their prices, there will always be bottom feeding app spammers (such as Brighthouse Labs) selling crap for $0.99.  So Atebit’s plan to release Tweetie v2 as a separate app actually makes sense (after setting expectations correctly).  But lets take it a step further.

I believe that we should be selling our software based on the time the user will use the app. Pick a value you want to charge per month of use, in this case, we’ll go with $1/month. Adjust these rates when/if prices in the App Store in general change. If you estimate your app has a 1 month life for the user, perhaps a game that will become boring/be completed in that time period, charge $1. If it's good for 3 months, charge $3. If the app is like Tweetie and useful for a year, charge $12. From here, we get my other possible solution (for the rest of us).

This option requires planning, so it's too late for Tweetie. If you expect a 6 month life of the app from v1 release to v2 release, price the app at $6. Each month drop the price of the app by $1. When v2 comes out, price it at $6 again. V1 goes to free, but is unsupported, or could even seize to function if that’s made clear to the user before they buy it. This is giving your users a set cost per month of usage. It’s not perfect, but much closer to what people expect, and it's a sustainable business model for us developers. I believe this will work extremely well if lots of us start using the model. This could likely be implemented via in app purchasing, by charging for each month of usage.

I’m going to stop here, without a final conclusion since I consider this just part of an ongoing discussion. I look forward to continuing to discuss these issues further and working with others in the community to solve these problems (among others) while creating successful businesses.