11 Apr 2017
Why I added an option to remove ads in 'Count The Days Left'
Following on from an earlier post about why I put ads in my Count the Days Left app,
I’ve now added an option to let users make an in-app purchase to remove those ads for a low, low price.
Why do this?
Two reasons really.
Clearly nobody likes ads, as they are very rarely relevant to what you are looking for. If you find them really irritating, you can now remove them.
Second reason is about money. It’s unlikely that I will earn £0.99 of ad revenue per user, especially as I’ve deliberately not put the ad in a
prominent place for taste reasons. If users do pay to remove the ads, it’ll be (slightly!) more profitable for me.
This approach also gives users the chance to say thanks if they like the app. Asking for money while giving something back somehow seems a nicer approach than using a “tip jar” I’ve tried before.
Live long and prosper
I was particularly pleased with my use of the 🖖 emoji in the in-app purchase screen.
Feel free to contact me via Twitter at @yeltzland if you have any thoughts on any of this.
07 Apr 2017
Following Workflow's acquisition by Apple, my thoughts on where (I hope) they might be heading
As the whole iOS world knows, the excellent Workflow App was acquired by Apple last week.
IMHO Workflow is an essential part of using iOS productively, and I’ve already written a couple of times about how I use it.
I’m hoping the acquisition won’t going to turn out badly (although history shows it’s a real possibility), and I’ve been thinking about what Apple’s plans may be - quite possibly wishful thinking.
Current situation with x-callback-url
Many of the automation features in Workflow depend on apps implementing the x-callback-url specification. This method, which piggybacks on the iOS URL Scheme is an elegant
hack to solve inter-app communication problems in a way that just aren’t possible using existing iOS extensions.
However, it’s unlikely Apple are happy with this as a long-term solution - in particular x-callback-url has no notion of security and can easily be abused.
Siri intents
Apple are already working towards allowing users to control apps without directly opening them up via Siri.
iOS 10 introduced Siri intents via SiriKit. This allows you to pass commands
in pre-defined intents to apps that support them, and allow those apps to response in a structured way.
Clearly this is similar in usage to those functions exposed via x-callback-url.
Apple’s usual deliberate progress means Siri intents are only available in a limited number of domains right now (including VoIP calling, Messaging, Payments, Photos, Workouts, Ride booking).
I’d be shocked if this list isn’t greatly expanded in iOS 11. Hopefully we’ll find out more at WWDC 2017.
Some predictions
1. Workflows will be able to be triggered via Siri
This seems a no-brainer, and a great way of how the existing Workflow app could be greatly improved by being owned by Apple and having access to internal services.
Maybe even by iOS 11?
2. Apple will allow apps to add their own intents
This is definitely more speculative. Apple likes to tightly define what apps can and can’t do, so it feels too early for it to be opened up right now.
Also, for multi-language Siri support - something Apple does much better than Amazon right now - it’s clearly easier to support a smaller set of intents and gradually roll them out as the voice recognition models are trained.
However, if the intents were not just for voice, then there is less reason to restrict developers in this way. If an app could define its own intents for other apps to call them in a standard way, this could cause an explosion of automation opportunities.
I can’t see this happening in iOS 11, but would love to be proven wrong.
If apps could offer standard entry points as outlined above, then it would make sense that Workflow would switch to using them.
In fact if Workflow only supported calling intents (rather than x-callback-url entry points), that would be a strong incentive for app developers to switch to the “official” way of exposing entry points.
It also feels much more like an Apple way of doing automation.
Summary
I’m really hopeful the acquisition of Workflow was done to extend and improve iOS automation, rather than just an acqui-hire of the founders.
If my predictions are correct, I think we’d have a powerful system to allow our apps to be automated, and an extensible system to write secure and powerful scripts to tie apps together (that is integrated with Siri).
I’d be very happy - and shocked 😊 - if any of this comes true.
Feel free to contact me via Twitter at @yeltzland if you have any thoughts on any of this.
12 Feb 2017
Where I try to justify - mainly to myself - why it's OK to put ads in 'Count The Days Left'
I recently released a version of my Count the Days Left app which included ads for the first time.
I thought long and hard before doing this, so I thought it might be interesting to document how I worked through this decision, as it’s pretty typical
of the trade-offs independent software developers have to make.
How I make money
I’ve been a commercial software developer for nearly 30 years now (wow!), including over 10 years working at Microsoft (MSN/Bing/Skype).
Right now, I split my time between:
- Contracting out my skills to businesses for fixed-term projects
- Building mobile apps and websites for businesses
- Developing my own iOS and Android apps for both pleasure and profit
In 2017 I’m trying to diversify my business more, so the 3 areas above contribute more equally to the bottom line.
Currently, by far the biggest part of my income is working on contracts for other people,
and I’m trying to generate more independent streams of income so I can be more in control of both my time and where I work.
Why I built Count The Days Left
I built the app for a few reasons, but mainly:
- I wanted to showcase my skills to generate potential business
- I wanted this app for myself, and most of the alternatives in the App Store were either ugly or not quite what I wanted
For the first point, I’ve blogged extensively about how I’ve built the app,
as well as open sourcing the code on GitHub so potential customers can see my work.
The app has been pretty successful in meeting these aims, and has definitely helped in generating business (although it’s hard to measure the actual monetary value of this).
As you’d expect from a simple and niche app, it doesn’t have masses of users - daily users are definitely in the hundreds rather than the thousands.
In fact, some of the features (showing the days left as an icon badge, the Today widget, plus the Watch complication and app) are designed so the users don’t actually need to open the app every day, but I’m pretty proud of how it’s turned out.
Monitising the app
For any iOS app, there are three main ways of making money from an app:
- Charging to buy the app
- Adding an in-app purchase or subscription, probably to unlock additional functionality in an otherwise free app
- Adding ads
Now, unfortunately I suspect there is very little chance I’d sell many copies if I decided to charge for the app.
There are so many free competitors to this particular app, and even if my app is better than them - and obvioiusly I think it is :) - it’s very hard to
see how many customers would agree.
People are now so used to getting high-quality free software, generally from venture capital backed companies who are happy to lose lots of money
to capture large audiences in the hope of monitising that audience later. That makes it a very hard sell to convince people even to spend $0.99 on an app that
might provide them with lots of value.
Personally I’m happy to pay for good software, especially from independent software developers who are doing great work.
However I completely understand why most people
don’t think in that way, and as I can’t see the situation ever changing, for most consumer apps I can’t see there’s much point in even charging a very small amount.
Now this particular app only really does one thing (although hopefully it does it well!), so I can’t see any sensible way of adding “pro features”
to be unlocked by an in-app purchase.
I guess I could try a patronage/shareware model, and ask for money to support the app?
I’m not sure that would actually generate any money without some sort of persistent nagging which I don’t think I’d be happy with.
This probably gets to the nub of my problem with all of this discussion. I’m not sure if it’s a British thing, but the conflict between needing to get paid and
somehow seeming to be only doing it work the money is complicated.
I do want people appreciate and enjoy the app, and somehow this should be separate from the dirty business of getting paid.
So this just leaves adding ads.
Tasteful Ads?
I didn’t want the app’s main screen to show ads at any time. I think its’ main selling point is it’s a tasteful and good-looking app
(especially compared to some of my competitors), and slapping an ad there would completely negate that.
Therefore only other place left to put the ads is on the settings page, where you change the title, start and end dates of what you’re counting down to.
I’m reasonably happy with this compromise, although from a pure money-making point of view this page is not viewed very often, as the users only go thereevery time they start a new countdown.
I’m using Google to provide the ads via AdMob, and have customised them to be text-only and in a color that matches the rest of the app. At least in that way they are not too
jarring, and fit in as well as I can make them.
As you can see from this example, the way the ad looks is OK (even though the content is frankly a bit shit)
Is it worth it?
In the first week, I’ve made a few pennies - slight more than I expected, which was very little be honest!
However, I’m generally happy I’ve done this. I think it’s important all software developers get paid fairly for their work,
so turning the tide against the idea all software should be free - even the the smallest way - is OK.
Probably.
Obviously giving Google even more data is not “free” for my customers, as they are now paying for the app with their information.
I’m not 100% happy doing that, but as I’ve hopefully explained here, it’s a complicated trade-off.
Feel free to contact me via Twitter at @yeltzland if you have any thoughts on any of this.
Update (2017-04-11)
I’ve now added an option to pay to remove the ads - read about it here
05 Feb 2017
As I’ve written about before (read here and here
for some background), I’ve got a crazy-complicated system to manage my shopping list, involving my Amazon Echo, Todoist, IFTTT and Slack.
The original system was working OK, but it had several non-optimal parts including:
- Getting a notification every time I was near the supermarket, whether there was anything on my shopping list or not
- Even if there is anything on the list, I get the same alert each time
- Ideally I’d like to see what is on the list in the notification, rather than just a link open Todoist. That would mean I can see on my Apple Watch
what I need to buy without having to get my phone out.
New “Architecture”
I thought I’d draw the new, improved setup on my whiteboard to make it a little clearer to explain …
IFTTT Maker
When I was building the original system, I didn’t know about IFTTT Maker Channel, which can:
Integrate other services on IFTTT with your DIY projects.
You can create Applets that work with any devices or apps that can make or receive a web request (aka webhooks).
This is fantastic, as you can really build some complex systems that hook into your own logic. So with a little more work I can now build exactly the setup I want.
New Service Logic
The logic for Shopping List v2.0 is as follows:
- Setup two location-based IFTTT applets that trigger when I am near the two Hexham supermarkets (as before)
- The “that” part of the applets now simply make an API call to my web server (passing a secret authentication token for security)
- The web service, on receipt of an authenticated call, will:
- Call the Todoist API to see if there are any items on my shopping list
- If the list is non-empty, and has changed since the last call to the service, make a HTTP call to a third IFTTT applet (passing the shopping list details as a parameter)
- The third IFTTT applet simply coordinates the incoming parameters into a Slack message sent to me
You can see the results from yesterday’s trip here:
The first alert was when I got to Waitrose, and after I’d crossed off 3 items from the list in Tododist, when I got to Tescos it then reminded me about the final item.
I’m pretty happy with this now. It really is great to use Alexa as a way of managing our shopping list, and I don’t use any other way of doing it any more than by voice.
Yes, it is a pretty nobby list of things to fetch (I was going to Waitrose after all).
And no, I never did get the Sausage Casserole mix. It appears Hexham is all out right now.
27 Jan 2017
Version 2.3 of Count The Days Left has now hit the App Store for your viewing pleasure.
I finally got around to upgrading the code to Swift 3. The Xcode migration code did a reasonable job with the syntax changes, but missed a few things around interface changes - especially in the WatchOS code - that
I had to fix manually.
I also fixed a very minor logic error in the date calculation in the settings page. Quite amazing it had been sitting there in plain sight for a long time without me noticing it.
Not much more to do in the app right now, but maybe WWDC in the summer will bring some exciting new areas in which to play in?
