Apps & Software (14)


Why I’m Excited about watch OS 2

For those who don’t already know, I have Repetition Workout Counter in the AppStore for iPhone and iPad. The most recent release – version 2.0 – added support for Apple Watch from day one.

I didn’t quite know what to expect out of the Apple Watch. It’s quite an elegant piece of hard ware and software engineering. That is, until you start using third-party apps. The issues I (well, and many others) have is that running the app as an extension on the phone and communicating UI changes over Bluetooth has been problematic. It’s slow. Sometimes it doesn’t connect.

In the case of Repetition, it only does two things – increment a counter, and control the stopwatch function. At times even these are painfully slow – and I’m only sending minimal payloads (most often a single key:value pair) over the air to the Watch.

Now, enter watchOS 2, announced yesterday at WWDC. This is what we developers have been waiting for – the ability to run apps natively on the Watch, some UI improvements, access to hardware components, complications, and more.

For apps like Repetition, that means some key advantages over WatchKit:

  • Immediate UI updates. (counter and timer are immediate)
  • Haptic feedback from the taptic engine (say, a little buzz every X minutes)
  • Better heart rate monitoring
  • No need to be near your phone during workouts.
  • Watch face complications with the current reps and timer w/o having to open the app

So, you can see why we’re excited for these enhancements. I really think the watch is perfect for two things – notifications and exercise. With Apple pushing the Health aspect so much, I wouldn’t be surprised if they felt the same way.




July 2014: We Noticed Indie Died

It seems July 2014 may go down as the month when we realized being an indie (iOS) developer is no longer feasible. It’s not that something suddenly happened, rather, we collectively realized the same thing: there’s no way to make a living doing this.  Rather than making a living off of developing one or two apps, we need to find another source of income and do this on the side. It’s the only way.

Here are some recent posts by notable developers in the community. They hit on a few different woes, and points. Some implore we approach this whole thing from another direction.

 

A Candid Look at Unread’s First Year

More on iOS Indies

Shopster 2013

iOS Indie Game Numbers

App Rot

Organization

The iOS Indie That Could

Trials and Updates are Still Dead

On Pricing More

App Store Realities

Why I Left Indie Development

Where are the Indie iOS Developers You Ask?

The Mobile Software Disaster

Another Non-Indie Developer App Story

The New Indie

 

I fall right in line with many of the experiences expressed in the aforementioned links. In the early days of Pivotal Action, we were starry-eyed at the possibility of creating something great that people liked, with the “reasonable” hopes of being successful. We started off with Completion, and later went on to work on a new project, Pixd, that never shipped (though it was close-ish). By the time we more or less gave up on Pixd, I think we had realized the return on our time investment was unlikely to pay off. Even as the dust was still settling with Completion, we knew we couldn’t quit the consulting side of the business – it was paying the bills.

[UPDATE] I’ve added additional links showing more experiences and perspective on the indie situation




An Overview on Providing OAuth for Your Mobile App

I was recently playing around with an idea – a proof of concept – for an mobile app API. If you’ve never done this before, keep reading.

The high-level requirements:

  • A mobile app that you have control over
  • An API you’re working on
  • Users must be authenticated

As I am the app and API owner, I thought it best and easiest to use a two-legged OAuth implementation – username & password plus some secret keys (3-legged vs 2-legged explanation). This is what your users will expect when logging into your app & service. Before you can start, find an appropriate library for your web framework. There are plenty out there, so pick your poison. I’m familiar and develop relatively quickly with CakePHP, so I went with seddonmeida cakephp-oauth-server. I’ll spare you from too much code.

First, you’ll have to set up an OAuth client in the database. This is for your app and nobody else. Follow your library’s instructions; you’ll find out you can’t read values from the database because they should be hashed. Once you have it installed and are sure it’s working, you can start the setup. In the CakePHP plugin,

Save your client_id and client_secret in a safe place. You’ll need it in your app. Now, the fun part. You can test this in your browser, but it will work the same way in your app.

First, Grant the Token

In OAuth terms, we’re doing a password type grant with the client_id and client_secret.

https://domain.ext/oauth/token?grant_type=password&client_id={SOME20CHARACTERLONGID}&client_secret={some40characterlongsecretkey}&username={username}&password={password}

You’ll get JSON in return with a few important keys, namely access_token and refresh_token. They will serve as your ID badge for future requests. Keep them around. NB: access_token is used most, but refresh_token has a special place.

Request Something

Making a request for protected resources is easy. Assuming your back-end is set up properly, you should be able to run something like this with no problem:

https://domain.ext/oauth/userinfo?access_token={whateverAccessTokenYouWereGiven}

I know the above URL is at /oauth/, but that doesn’t mean your entire API has to be handled with your OAuth controller. In practice, you should include your OAuth library as a component of each appropriate controller wherever you’re accessing the API, or at least secured content.

Refreshing Your Token

A lot of services using OAuth aren’t going to expire your token. Seddonmeida’s implementation uses an expiration, but in practice doesn’t actually enforce it; that’s up to you. In the case you do have an expiring token, it’s best to refresh your user’s keys from time to time so they aren’t “logged out.” To get a fresh new token, access our OAuth token action and request a refresh_token grant type using the client_id, client_secret, and the refresh_token you received when first authenticating.

http://domain.ext/oauth/token?grant_type=refresh_token&refresh_token={youGotThisAtAuth}&client_id={some20charid}&client_secret={a40charstring}

A Note About HTTPS

Make these requests over HTTPS if you have any option at all. Otherwise, HTTP is sending your username and password over in cleartext, which we all know isn’t a great idea.




Underwhelming Android Experience

Ryan Heise summed it up nicely in Four Months With Android. I used an HTC incredible for 11 months. There are some great things about Android, but the negatives far outweigh the benefits for me. Android was just underwhelming. The UI and UX isn’t as nicely polished as iOS. Android apps, on average, just aren’t as well polished. Android reminds me of Windows of years past. Sure, it more or less works, but it’s just not that great of an experience.




Will Hybrid Mobile Apps Prevail Over Native?

I’ve been wrestling with this question for some time, and I thought this post may help sort out my thoughts and opinions while giving you some important insight. Are hybrid mobile apps going to become the developer’s choice anytime soon? The debate can be pretty heated as companies choose one technology over the other.

Hybrid, the Unlikely Union

Let’s get the definitions straight before we begin. A hybrid app is one of those mobile apps that uses a native web view to display HTML, CSS, and JS “web” apps. They’re only sort-of “web apps” because they are run locally, though they often pull data from online sources via AJAX requests. So, you have this HTML/CSS/JS app running inside of a natively-compiled stand-alone web browser of sorts on your phone. One such example is PhoneGap. Because the logic bits of the app are written using web technologies, you can often develop once and deploy on multiple platforms, so long as you’re using supported markup. You’re killing multiple birds with one stone.

Hybrid is the Bee’s Knees

As I mentioned above, hybrid technologies are great for developing cross-platform apps. Seriously – since iOS, Android, and even some Blackberry devices are both running Webkit most, if not all, your html, css, js is going to work remarkably similarly on both platforms. It’s pretty enticing. From your and your client’s perspective it’s a pretty easy sell. For one round of development you have the potential to hit many more users. It’s pretty cost-effective. Pretty soon you’re singing the praises of your decision and you’ve decided that from now on hybrid apps are the bee’s knees.




Catching Android’s Back Button in PhoneGap

This little bit of code is going to be useful to those of you developing a “singe page” app inside of PhoneGap. This applies to Sencha Touch (big fan), but doesn’t as much to jQuery mobile and jQTouch, as it’s a multi-page/navigation based event framework (it uses the app’s url string to do things like move around to different link anchors). This is really important on these single page apps because the Android hardware back button will send the PhoneGap app to the background. You need some way to intercept it so you can start building your own history management mechanism. Sounds fun, right? It’s actually not that hard.

On app initialization, add an event listener for Android’s back button, and the callback to handle it. PhoneGap takes care of the interface between Android and your app.

That’s enough to get you started, and it should be pretty apparent if it works or not.

How about history management? It will depend on the app and what makes sense, BUT you’ll probably want to create a history array, and pop off some value that directs the app each time you hit the hardware back button. Here’s another idea: change the destination of the back button depending on the view. I personally like the idea of the latter because apps built on Sencha Touch are going to have easy tie-ins through predefined listeners JS Objects that define screen elements like buttons.




Mobile Platform Detection on the web

I had a use case recently where I need to determine whether the client browser was a desktop/laptop/etc or a mobile device that supports tap events in JS. This will be useful to people who are dynamically binding different events to elements.

You would use it like this




Case in Point: Orbital iPhone App

Check out this article in TUAW about how an iPhone app, Orbital, isn’t really making it for the developer after less than (nearly?) 100,000 units sold. The article suggests it’s just a case of bad luck. True? I’m not so sure. Here’s why.

Saturation

It seems to me that the App Store is pretty saturated. To clarify – the iPhone App market feels pretty saturated. I don’t mean that good apps don’t come along from time to time, however the sheer volume is daunting. I searched the App Store for “Camera” and came up with about 1200 matching apps.

Marketing

Face it, you can’t rely solely on the App Store to do all your marketing. Get into the top lists and you’re got a pretty good shot of doing well your first couple days. If you don’t, good luck with getting potential customers to find your app out of the thousands that accompany it in the store. It’s time to get involved with good ol-fashioned marketing – just like every other product in this world. Pretty soon developing profitable iPhone apps looks a lot like developing the boxed apps, but without the boxes and retail chain.

I think I’m done blogging about this for a while. Nothing like beating a dead horse.




Thoughts for the App Store

With regards to last night’s post on App Store pricing itself into an unprofitable wasteland, I thought of something.

What if there were two versions of the App Store? One for inexpensive, useless, or just plain bad apps, and another for apps that met certain price, quality, or other criteria?

For those wishing to make iPhone development their business, the current version of the App Store isn’t the ideal marketplace. Finding apps can be challenging – either your searches aren’t quite coming up with what you’re looking for, or you have to wade through pages and pages of apps that don’t interest you. The other problem is the pricing competition with people who may not have similar economic goals as you do.

App Couture

Apple could offer different development tiers. Break the App Store down into groups indicative of where developers enroll. Keep the $99 price point for individuals. After that, add one or two more tiers for the ambitious or the corporate developers – maybe at $499 and $999. I don’t think Apple needs to add additional features. The benefit from joining the higher tiers is that you get placed in the App Store Premium. It’s App Store Couture. Could you also maintain a category for ad-free apps? Never mind the small advertising on the info/about page. I’m talking about those annoying little pop-ups at the bottom of your screen.

With those benefits are going to be some pitfalls. Just because somebody pays several hundred dollars for the premium listing does not ensure a quality product. And what with the fees you pay, will Apple do with it? It’s not up to me, but if it were – how about using some of that extra cash to improve the approval process?

App Graveyards

Let’s take this another route –  take old apps behind the barn, à la Old Yeller. Ok – maybe a bit extreme. Why not make an app graveyard where old apps go to die. By placing certain requirements on how often apps must be updated, Apple could, in theory, keep the App store fresh by keeping new and newly updated apps, while throwing the abandoned ones to the App Store Graveyard. In all likelihood you’re probably not interested in using many of the apps first developed when the iPhone was released. It’s not too big a task for developers to make small, incremental changes on a regular basis. It’s a sticky place to be in. On one hand you’ve spent a lot of time (money) on developing an application, and now you have to spend more refreshing it every so often. The updates might not drive new sales – money wasted, so to speak. Could that problem be solved by simply having to re-submit apps once a year? Uncertain. Surely it would produce some undue burden on the app approval team for apps they’ve already approved before.

Indies

Who wouldn’t like Apple to open up the distribution channels to third parties? I could see this open the possibility for independent virtual storefronts where retailers have the ability to pick and choose the apps they feature through their store. This approach has two possibilities that I think could work. First – Apple could open the iTunes AppStore to an affiliate program: App Store Indies. Online retailers could list apps on their website, but the whole thing link back to iTunes, as it does now. The second scenario would be the ability to distribute apps outside of iTunes, but still retain that special Apple-certified seal of approval that is required already. The apps, registered and digitally signed through Apple, could be available for download, or even boxed up and sold in block-and-mortar stores. There would have to be an economic incentive to Apple and the retailers to make this work. Because Apple owns the only distribution channel, I don’t see any reason why they would want to change unless it meant more dollars for them. That could easily be achieved through higher-priced premium apps. As a consumer, I like the idea of multiple outlets because I come to know and trust certain retailers and go back to them repeatedly. The cream will rise to the top – those retailers selling good apps will succeed, but at least they have the incentive to not bend to the price wars.

Am I biased? You betcha. As a developer, I want to make sure that I can make a living out of what I do. I can’t afford to spend hundreds of hours on projects for the chance of making one or two thousand dollars, 99¢ at a time. The App Store may have become a popularity game, but that doesn’t mean it should do so at the cost of making a living – especially if the iPhone platform is going to continue to be a profitable platform for the developers. If the money leaves, so will they.




Race to the Bottom: iPhone App Store Pricing

I’ve had a notion for some time that the price wars on the app store may be detrimental to the community. I know I’m not alone in this feeling, and have found others online who would agree. Finding like-minded developers isn’t my goal. I’m wondering when, or if, the App Store will begin to resemble something a little closer to desktop boxed software prices.

I think it would be wrong to assume that mobile apps will reach the cost of boxed software. However, I do believe we’re shooting ourselves in our proverbial feet by pricing perfectly good applications at free or even $0.99. Admit this – comparing a $0.99 app to a $2.99 one, both with similar features, ratings, and quality user interface, which one are you more likely to buy? If you were the guy selling the $2.99 app, wouldn’t you feel compelled to lower your app’s price even just a little? I mean, some money is better than none?

Assumptions

You’re going to make a few assumptions, be it good or bad, but one way or another they will affect your sales. These probably fall into two or three areas, 1) lowering your price will communicate better value; 2) lowering your price will increase sales; 3) more sales means more profit.

Better Value?

That’s open for debate. Customers may think they’re getting a great app for cheap (high value), or they can see a lower price (whether your are lowering the price or setting a low initial offer) and think nothing of it because everything else in the category is priced roughly the same.

Increased Sales?

This might also be true. It almost goes without saying – people can buy more cheap apps on the same budget than pricey ones. I’ll give you a +1 for remembering the concept of supply-demand curves you learned in your high school econ class. There is, unfortunately, a wrench thrown into your increased sales equation – anecdotal evidence points to the best sales occurring right after launch and eventually falling off after the 60-day mark. We’re working with a limited time frame to make the most we can.

More Sales, More Profits

All things being equal this becomes a matter of math. Cutting your app’s price in half means you need to double sales to make the same amount of money. Do you think you can do that? Realistically? In the 60-day window where most developers see the largest chunks of their sales?

Closing Thoughts

I’m going to finish up with one thought that should bring this full circle. Before pricing your app consider the cost of the downward price war. You may make more sales, but you won’t make a decent income off of it. Should this trend continue, our users will become spoiled enough that they will hardly tolerate higher priced apps unless they are truly unique and worthwhile. This price war is only hurting ourselves and something will have to change or the App Store will end up a wasteland of low-quality apps because the true developer dollars will go elsewhere, thus making the iPhone/iPod Touch platform much less appealing for everyone.