Today Apple updated the App Store to show the word “GET” instead of “FREE” for free-to-download apps. Jason Snell has a good write-up of the change on his site, Six Colors. The basic premise is a reasonable one: A lot of apps labeled “free” aren’t really free. They’re free to download, but you can (and often must) make in-app purchases in order for them to be useful. For those apps, the “free” label could be misleading.

Nonetheless, I have a few concerns with the change:

• It doesn’t differentiate between apps that are “free with in-app purchases” and apps that are just FREE. I think it’s worth labeling apps that are free with no in-app purchases as such.
• The “GET” label doesn’t give users enough information about what will happen when they download the app. Unlike the “FREE” button, it’s not immediately obvious that you won’t be charged when you tap “GET.” True, there’s no price listed, but you do have to enter a password or fingerprint using Touch ID. I’m sure that’s enough to raise concern among some users that they’re about to be charged money to “GET” the app.

I propose two changes that would go a long way toward easing user confusion:

• List totally free apps (those without in-app purchases) as “FREE.”
• Replace the “GET” button with either the iCloud download icon or change the button text to “FREE TO DOWNLOAD.” The former is used elsewhere on iOS in situations where no money changes hands, and the latter uses much clearer wording than “GET.” Browse screens, such as the App Store home screen, could retain the “GET” label to save space because it’s not a button in that context.

Reading (Underscore) David Smith’s excellent post about expectations for WatchKit got me thinking about some of my own. The idea I keep coming back to is: Wouldn’t it be interesting if WatchKit APIs were Swift-only?

Swift-only Watch APIs wouldn’t prevent Apple from re-using other iOS APIs on the Watch. (I’m assuming that Watch OS will be some variant of iOS.) Because Swift can access Objective-C APIs (albeit a little awkwardly), Watch apps could still use existing APIs that make sense across devices. (Take the notifications and extensions APIs as an example.) Basically, Apple would do what we’re all expecting them to do eventually: Make new APIs Swift-only, without backwards compatibility to Objective-C. Existing apps that don’t need the new APIs, like iPhone apps, would continue to run just fine. But if you want access to the new goodness (including new devices), you have to write some Swift code.

The Watch represents Apple’s best opportunity to jump-start their new language in a production context. There will be a lot of developer interest in the Watch, and this gives Apple a chance to push developers into giving Swift a try. Apple has been extremely aggressive in pushing new versions of their OSes and developer tools, and this is a chance for them to go further. Most developers I know are hesitant to use Swift in a production app because it’s so new. That situation could persist for years unless Apple gives us a little nudge or two.

The Watch is an ideal candidate for that kind of nudging. It doesn’t have the backwards-compatibility issues that the iPhone and iPad do. Nobody needs to maintain support for previous versions of the Watch OS, because they don’t exist. Nobody will complain because they have years of experience with the old way of doing things on the Watch, because there is no old way. Just as the first version of the iPhone SDK set the tone for iOS development, the first Watch SDK will set the tone for Watch development. Now is Apple’s chance to make that tone be Swifty.

Of course, we have no idea whether the Watch team knew anything about Swift before WWDC. It sounds like Swift was as much a surprise to many Apple employees as it was to the rest of us. If the Watch folks didn’t know about Swift, it’d be extra work for them to go back and update APIs to be Swift-only. But wouldn’t it be just like Apple to go back and remove Objective-C compatibility, or make things Swiftier, just to promote a larger objective?

Either way, with the Watch SDK set to drop sometime this month, we won’t have to wait long to find out if I’m right or spectacularly wrong.