Apps & Software

This project has been near and dear to my heart long before I wrote a single line of code. That said, I think it’s understandable I”m pretty nervous about this pre-announcement. BUT, I also look forward to helping people change their lives for the better. Count this as a semi / unofficial announcement. :)

Several years ago I started getting more serious about my health and began searching for fitness methods that worked. I actually had a lot of trouble finding something that gave me results and was interesting enough to keep doing it. Running wasn’t it. Getting to local hiking spots was too time consuming. Attending the big gym down the road was overwhelming with all those machines (and therefore ineffective). Personal training was way too expensive. What I found wasn’t a set or specific routine or program that gets old after a while (you know those videos you can buy). It also wasn’t a fad celebrity workout.

It took a few years, but things finally started to click. I wanted something that reflected functional fitness to prepare me for “life,” and I needed structure to tell me what I should be doing. I also wanted a system that was efficient and effective. I’ve been doing this for a few years now, and I can say that it works for a wide range of fitness levels. Most importantly, this system is sustainable for a healthy lifestyle.

The app isn’t quite done yet, but we’re getting there. Count this as a first look as we start to get the name out in the wild. Head on over and sign up if you’re at all interested. From time to time I’ll send out sneak peeks, some insider-only info, and I’ll throw in a little bonus for you to make it worth your while. And don’t worry – I don’t do the spam thing. I treat you the way I would also like to be treated – with respect.

I have no set launch date, but it will initially be available for iPhone / iPad, and likely thoughtful integration with Apple Watch.

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.

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.

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,

Swift

1

2

3

4

functionsome_open_oauth_action(){

$client=$this-&gt;OAuth-&gt;Client-&gt;add('myapp://register');//the URL isn't really important in this case

print_r($client);

}

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.

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:

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.

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.

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.

There’s been a bit of confusion surrounding changes to XCode4 and PhoneGap. Right now the big ones are 1) Where did my PhoneGap user templates go!? and 2) How do I submit my PhoneGap-based app to Apple? Let me help you.

1) You want to create a new PG project, but you’re not seeing the XCode templates when you go through the new project menus. Check out Shazron’s blog @ Nitobi for a command-line script to get you a new project up and running. It’s not as sexy as the XCode template, but it will do.

2) You can’t compile your app for submission to Apple? That was a little more tricky to track down. See this thread on the Apple Dev Forums for a bit of an abstract view of what’s going on. I’ll save you the details. Follow these steps to XCode bliss.

Select the PhoneGapLib.xcodeproj entry in your files list:

Make sure the “All” tab is selected:

Look for the “Deployment” section and scroll down until you see the “Skip Install” parameter. Set Skip Install to YES:

EDIT: Make sure to verify your target device…
Make sure you have the “iOS Device” option selected in the schemes drop-down:

Go over to the “Product > Archive” menu. XCode will do its compile magic. Open the Organizer to see the app and the listed archives when the compile is complete. At this point, make sure you are ready to upload the app to iTunes Connect. Bonus: we get to skip the Application Loader app from now on!

Select the archive and click the “Submit” button. XCode will ask for your credentials. Log in and select the appropriate app and distribution profile from the list. Submit. If all goes to plan, you’ll get a message of approval. Finished.

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.

Swift

1

2

3

4

5

document.addEventListener("backbutton",backKeyDown,true);

functionbackKeyDown(){

// Call my back key code here.

alert('go back!');

}

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.

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.

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.

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.