I’ve been working away on my latest app, and was just creating a new piece of artwork for the splash screen. When I did this, I wanted to start with the iPad Pro 12″ and scale down within Photoshop to maximise the quality of each asset size.
For all of my other assets, I had started with the iPad for some stupid reason and got my math all confused.
So I went hunting for a guide, and found an old site from Ben Lew of Pi’ikea St. It was a little out of date, plus I really wanted to calculate the sizes using the iPad Pro as the starting point.
So I took Ben’s page and popped it into a spreadsheet. The result is available below for download. I’ve also taken a screenshot so that you can see it easily.
In Photoshop, something Ben taught me to do a few years back was to create a layer called “default”, and, in order to get Photoshop to export the various layers in my file as appropriately sized assets, add the sizes as percentages along with folder names.
For me, assuming my originals are for the iPad Pro 12″, this means I give my ‘default’ layer the name:
As some may be aware, the Parse service is to be shutdown on the 28th of January. Parse gave developers 12 months to sort ourselves out and find another place to host our data, and drive our services.
I’ve been using Parse for a couple of years now, to provide a push notification service to my uAlertMe app. I was looking at removing the app from the app store, and discontinuing support, because I couldn’t find a cost effective way to keep it all running. uAlertMe is an app that sells perhaps 200 copies a year, so there’s not enough income to cover monthly service fees.
Then, late in 2016 I saw a message on one of the local developer groups that Buddy had established a relationship with Parse, and were providing a wonderful migration tool to allow us, in a relatively pain free manner, take our data from the existing Parse service, import it into Buddy, and (hopefully) sit back.
Now I’d have to say that it wan’t quite that easy. Because I jumped on board pretty quickly, and because I wanted to use the Push notification system, I was wanting to use features that hadn’t been completely polished.
So, with some really terrific support from the kind folks at Buddy, I worked on getting everything working, and as of today, iAlertU and uAlertMe are happily talking via Parse on Buddy.
So, if you still haven’t migrated your Parse data, and are wondering what to do, you have 21 days (as I write this) remaining. Get on over to Buddy and get the process started.
You know, I think Apple and their incredible focus on accessibility is amazing. My daughter and I are currently waiting for Apple to review our first sticker app, called Heroes and Villains Stickers.
My daughter put all the artwork together, all drawn on her iPad using the ArtStudio app, and I did the “programming” bit (though programming is a stretch given Apple have made it so easy to put a sticker app together). This project is a labour of love for her, as she’s a real fan of the characters she’s drawn.
As we put it all together I realised that all those stickers had names, and that those names actually have function and meaning as you put the sticker app together.
Sticker Properties
When all was ready to submit, I got my daughter to go through all of them and name them with text that reflected the meaning of the stickers.
That has paid off in the final product as with voiceover turned on, tapping on a sticker causes the iPhone to read the name of the sticker out loud.
This is terrific as people with impaired vision can enjoy the stickers too, and send them to people that can see them, knowing that the sticker means the right thing.
It is details like this that make it easy for me to continue working with Apple and their ecosystem as I know that when Apple talk about inclusivity, they mean it.
I’ve been waiting to see what Apple would announce this week. I’ve been hoping for an excuse to upgrade my 2013 MacBook Pro (with retina), partly because I’d like some more storage (It’s amazing how quickly a 256GB drive gets filled once you start developing apps), and because my eldest is about to start University next year and I thought upgrading would mean I could give her my more than capable existing MacBook Pro.
At the moment, she’s working with my original MacBook, a 2009 white unibody MacBook which, as can be seen, has had better days. It still works a charm, though it’s been running hot, with all fans howling for a year or two now.
So, like everyone else working with a MacBook (Pro), I was keenly awaiting the refresh of the line this week. The rumour mills are pretty accurate these days, so we already had a fair idea of what to expect as a minimum, however to be honest, I’d been hoping for more.
I’d also been hoping for a realistic move forward from where I am now, and I really don’t think Apple have provided this.
Dongles Everywhere, it’s the future man…
Last year I saw the new 12 inch MacBook released with it’s single USB-C port and quickly wrote the device off as a waste of time. The lack of a separate power connector, and specifically, a MagSafe power connector was to me a huge step backwards. The smaller screen size made it doubly less attractive.
When I think about buying a new computer, I like to think I’m buying something that will allow me to continue from where I am, and transition over the next few years to a point where I’ll be ready for the next transition.
With the 12″ MacBook, and these new MacBook Pros, this is not the case. If I were to upgrade to one of the new MacBook Pro units, none, repeat, none of my existing peripheral hardware would be able to connect to it without these stupid, ugly white dongles.
Here is an image from dailytech.com showing the mess Apple is moving us towards (this for a 12″ MacBook, but you get the idea):
Every day, I connect to my MacBook Pro via the standard USB connector, various iPhone or iPad devices, other devices to charge, external drives for backup, and so on. Other people have more than I do.
If I were to ‘upgrade’ to one of the new MacBook Pros, I’d have to find a way to connect all of these devices via a USB-C port. What’s more I’d need to purchase a number of these ugly white dongles (why can’t I get them in a colour to match the MacBook I’ve just hypothetically bought?) if I want more than one plugged in at a time. Apple ‘kindly’ gave us 4 USB-C ports on these new MacBooks but that just encourages us to purchase more dongles.
Pricing
Note: OK, I’ll be quoting Australian dollar amounts here, but they should be indicative of other markets.
Here in Australia, the starting prices (it’s not even worth looking at the spec’d up prices, really) for each of the 3 new MacBook pros are as follows:
13″ MacBook Pro (no Touch Bar): $2199
13″ MacBook Pro (Touch Bar): $2699
15″ MacBook Pro (Touch Bar): $2999
Apart from the Touch Bar, there are some other subtle (or not so subtle) differences, the main ones being the speed of the CPU and the amount of storage.
Now, like many of you, and certainly, many iOS developers who, contrary to popular myth, aren’t living the high life off app sales, those prices just aren’t viable to me. My current MacBook Pro was bought as a refurbished unit from Apple, and it’s probably the way I’ll go next time now that I’ve seen these prices.
Apple are basically saying to me, “Hey Peter, we understand you can’t afford our sparkly new Touch Bar MacBooks, but you can always buy the new MacBook Pro without the Touch Bar. It’s only $2199!“.
My answer to this is that for that amount, I’d be buying a MacBook with the same amount of storage, a slower CPU, less connectivity, less expandability (I currently have a 128GB SD card in the SD card slot to expand my storage economically), and for more than I’d pay for a newly refurbished 2015 MacBook Pro with twice as much storage (see image to the right).
No thanks Apple.
I love your hardware, and I really enjoy the ecosystem you have created. My family is well and truly committed to Apple tech too, but this time around, we’ll be avoiding your new MacBook pros. If there is a new MacBook to be bought, it will be one that we can use now with the peripherals we have now.
So, I’ve been working on the tvOS port of Tap Tangram (due out, March 17!) and have a few observations. As some know, I like to use Cocos2D for my apps; it gives me a huge degree of flexibility for building the UI and doing what I want in the app.
One of the things I’ve been doing in apps for the past year or so is providing a lot of configuration options for the player, and what I’m finding now is that the UI I typically build for this on iOS just doesn’t work on tvOS.
Tap Tangram Player Editor
For one thing, the focus engine on tvOS does not like to play with non UIKit buttons and so on. If I have a name field which tends to use UIKit under the covers, I end up with a single UIKit object on the screen, and the rest are my own Cocos2D buttons and switches.
Now, back before the new Apple TV went on sale, I put a lot of time into producing a focus engine for Cocos2D that mimics Apple’s engine (you’ll find it in the tvOS branch of Cocos2D v2.2 here). It works really well, and I’ve used it in both GALACTOBALL and Tap Times Tables. It’s not quite as clever as Apple’s one, but it works quite well and has a flexible API.
I’ve updated this API to work with the latest version of Cocos2D, and have been integrating it into Tap Tangram, however on this player editor, tvOS won’t play nicely because it wants you to do everything it’s way.
The end result is that the UITextField is given focus by tvOS even when I don’t want it to. Apple, for reasons of their own have made it really difficult to control the focus engine in our user interfaces. It’s all UIKit, or no UIKit, unless you can find some tricky workaround.
In this instance I have not been able to find a work around that is satisfying. It feels clumsy.
So what to do?
Write a brand new UIKit Player Editor, that’s what!
After mulling over my nice UI and wondering how to squeeze that tvOS square peg into my Cocos2D round hole I realised that even if I got it to work, my UI just didn’t make as much sense on the TV. I look at those switches, and I want to flick them. I look at the slider and I want to slide it. On tvOS, this just doesn’t make sense because it’s not a touch interface even if you are using the Siri Remote.
So I decided to start from scratch, and write a basic UIKit UI for the player editor.
As soon as I started to lay it out I discovered that on tvOS, some of the user interface features we know and love, are missing. There is no UISlider. There is no UISwitch. How was I supposed to put a toggle switch on screen if Apple haven’t given us one? I took a look at the Settings app on the TV. Pretty much everything is done via tables. Toggles are simple table cells that when clicked, toggle their state.
I can do that for all those switches, but what about the slider? Well, at the moment, it looks like I will have to implement this as a cascading picker so that when the user clicks on “Maximum Value” it will change to a simple picker. It means less flexibility for the user, but ease of use.
The up shot of doing it this way is that I no longer have to worry about the focus engine because tvOS will do everything for me. The down side is that I’m going to have this screen (or two) that although very functional and easy to use, it will not look in any way consistent with the rest of the app.
In summary…
So, either way I have to make compromises. Do I stick with my own look and feel, and find a way to make it work, or do I take the “easy” path, use UIKit and accept that it just won’t look as nice (in my opinion)?
I’ll continue to experiment as I move forward. Unfortunately, the main game screen of Tap Tangram is a really really complicated combination of scrolling areas, buttons, and tangram pieces that can flip, rotate and be moved. I can’t take the UIKit approach there, so whatever I do on the Player Editor screen, I’m still in for some fun.
I’m about to embark on a collaboration with another developer. We want to create something new and fun. One of the first things to crop up is the tools that we use. In the interests of documenting what I use, I thought I’d write it as a blog post for all.
One of the amazing things about software development is that we developers can be very passionate about what we use, and how we use it. Some developers love getting their hands dirty by doing all the hard stuff themselves. Some like the ease of point-and-click programming (and there are some of that wouldn’t call that programming, but we’re probably being snobbish).
Me? I’ve been around long enough now to have got my hands dirty on a whole bunch of things over the years. I started out with AppleSoft Basic on an Apple IIe, and progressed through a whole suite of tools and languages until the Apple IIGS was discontinued in the mid-nineties. I could go on about those days and the years between then and the current “App” development wave, but that’s not what this post is about (if you want to hear more about the “good old days”, then let me know via comments; if there are enough then perhaps I’ll take a stroll down memory lane).
I won’t attempt to compare what I use against what others use here; this is simply a write-up of what I use, and briefly, why.
I would like to point out though that this post is probably best for other developers, or budding developers. I will use terms and jargon here and there that won’t mean much to non-developers.
Programming
Perhaps it’s something to do with my age and where I’ve come from, but I like coding by hand. Don’t get me wrong, I’m happy for an IDE (Integrated Desktop Environment) to do some simple stuff for me, but for a lot of it, I’m more than happy to type things out from scratch. The act of typing in code, even what might be template code to others, connects me with what I’m doing; it’s an opportunity to construct the tapestry as I work, to think as I type. Having a lot of it done for me means that typically, I’m allowing the tool to dictate limits and sometimes, it’s own design, on what I am creating. Coding by hand means that the limits are my own.
For iOS App development, my coding environment of choice is Apple’s Xcode. This is a terrific, free, IDE that comes with absolutely everything a developer needs to code an app and submit it to the App Store. Now I say everything, and it’s true, but in reality there are things like images, icons, sounds, documents, etc that also help to make up an app, and creation of those falls to other tools.
Apple has traditionally encouraged the use of Objective-C for all development. Most developers either love or hate Objective-C. I actually enjoy it as a language. When Apple introduced Swift in 2014, I was a bit surprised. I knew that lots of people don’t like Objective-C, but I didn’t think people would be so happy to see a replacement. Swift has so far managed to fail to capture my attention. I have no desire thus far to change; Objective-C works, and works well.
App User Interface
Apple, for the iOS environment pushes it’s own UIKit and I’ve used this in several of my apps. It works well, and it’s very powerful. I don’t however like to use UIKit for the educational apps, and games that I create. For these I have used Cocos2D. I’ve been using Cocos2D since it was version 0.99. It’s now up to version 3.3. Most of my educational apps use version 2.2 of Cocos2D, though future apps will most likely use version 3.3 or later.
This GIT repository contains an entire Cocos2D project that I put together to demonstrate the use of Apple’s Accessibility API in conjunction with Cocos2D.
Going forward, Cocos2D is now integrated into a new IDE called SpriteBuilder, which is freely available at: http://www.spritebuilder.com, SpriteBuilder provides a very powerful environment that allows you to design the UI of your app in a way that can be built for both iOS and Android. I have yet to test/try the Android side of things, but feedback from other developers who have used Apportable which has been integrated into SpriteBuilder, has been very encouraging.
SpriteBuilder creates, from your design, and entire Xcode project that you can then add code to, and build for submission to Apple. They integrate well, and the powerful thing is that once you open up the Xcode project, you can forget about SpriteBuilder if you choose and hand code the rest of the app. I really is, for me, a good blend of the two.
If I’m building a UIKit app, then I do everything in Xcode.
Code Management
When I first started working with Xcode, I used “cvs” to manage and control the various versions of my code. It worked well, but in the years since then, the development world has moved on. These days, the trendy choice is “git”, and for me, it’s a good choice. It works well in a local environment, and I’m able to set up remote environments so that I can easily backup my code to a file server, or the cloud.
For code version control using “git” I used SourceTree, by Atlasssian. SourceTree is available for free from: sourcetreeapp.com It’s a great tool, very powerful and integrates beautifully with a cloud based service called BitBucket, also by Atlasssian. I use BitBucket because I can create unlimited private repositories for free, and it’s very handy for sharing code with other team members. I use SourceTree on my Mac to manage daily commits of code, and then push those commits to the cloud or a file server periodically so that I have backups.
Artwork
For a lot of my apps, I’ve created most of my own artwork. Until late last year I did all of this using a free app called “GIMP“. It’s a great tool, and for people, like myself, who work on a very low budget, it works well. It’s cross platform and there’s even a version on iOS called ArtStudio (though they don’t call it GIMP, when you look at it’s feature set, and menu structure, I’m convinced that’s it’s built from a GIMP codebase).
With the new version of Money Up, I moved to the Adobe Creative Cloud suite, and Photoshop. Whilst I enjoyed GIMP and became proficient using it, I now really enjoy the power provided by Photoshop and the higher quality outputs achieved by using Vector based shapes for the drawings. GIMP is a raster based editor, and as such, is unable to export cleanly scaled images in the same way.
Sound and Music
Before I mention the tools I use on my Mac to edit sounds and music I want to mention two websites I use to source most of my sounds and music:
incompetech.com – This is a wonderful site by Kevin MacLeod who shares a vast library of his original royalty-free music. I’ve used a number of pieces from this site; the ability to browse using a terrific filter makes life much simpler.
freesound.org – This site is a powerhouse, full of sound recordings. Be careful to observe the licenses attached to individual recordings.
For most of my sound editing, I use Audacity, a free and yet, very powerful sound editor. When I needed to clean a large number of sound recordings for Money Up however, I used Audition CC, part of the Adobe Creative Cloud suite. For me, it’s not as intuitive as Audacity however it’s very capable, and some things are easier to do.
I always export my sounds as “AIFF” files, but I don’t use those within the apps that are submitted to Apple. Most apps don’t need high quality sounds, especially for simple sound effects. What I do, is run a short script over all of my “AIFF” files, to convert them to “CAF” files which take up less space, but still sound just fine on an iOS device.
This script comprises:
#/bin/sh
FILES=`find . -name \*.aiff`
for F in $FILES;
do
DF=`basename -s .aiff ${F}`
echo "Converting ${F} to ${DF}.caf"
It’s been a busy couple of months since Apple released iOS 8, the new iPhone 6 and 6+, Yosemite and … hold on, this post is supposed to be short. If I list everything that Apple announced, I’ll be here all day!
On with it. Since Apple’s big event, I, like most other active app developers, have been very, very busy. I’ve been working away at a new app for special needs education, and a complete rework of my first special needs app, Dollar Up. I’ve also had to update all of my apps to be sure that they work on iOS 8.
As if that wasn’t enough, I’ve also written another new app called 9 Letters which is due to launch this Thursday, the 20th of November. 9 Letters is all about letting the inner word searcher go mad. If you like Scrabble™ or Boggle™, or just about any other word game, I think you’ll like 9 Letters.
One of the really neat features of iOS 8 and Yosemite is Continuity. I love it; it brings to the Apple devices a wonderful synergy where they work together to become a single powerful tool that anyone can use. No more do we have to close a document, save it somewhere special and then reopen it on another device in order to continue our work. We can now just Handoff the document, in it’s current state, from one device to another.
When I was nearing completion of 9 Letters I realised that the game would benefit from this neat feature in iOS 8, so with a remarkably small effort (Apple really made the process very easy) I added Handoff to 9 Letters, and I love it.
Now, when I am on the train home from my day job I can play a game of 9 Letters on my iPhone, and then handoff the game to my iPad when I get home. It really is great.
Below is a short video I recorded tonight that tries to demonstrate just how great this is. I hope you enjoy it. I also hope that other developers get behind Apple with Continuity and all it offers; working with computers and mobile just got even easier.
With the advent of iOS 8, Apple has added what it calls “App Previews” to the App Store so that developers can showcase their apps with an up to 30 second video of their app.
These videos are supposed to be simple screen captures, with perhaps a little post editing done in an application like iMovie. They are not supposed to be anything more than that. With that in mind, Apple have made it pretty easy to record your App Preview and upload it to iTunes Connect.
Even so, it seems that some people are still struggling with what tools to use, and how to get a file that they can upload that meets Apple’s rules.
The main things you need to take into consideration are:
The video must be less than 30 seconds in duration.
The video must be less than 500mb in size
The video must be the correct resolution. For this, the resolution depends on the device class you are submitting the video for. When I submitted my videos, the iPhone 6 had not been released so I had only to create videos for the iPad and iPhone 5. Apple don’t allow us to create App Previews for the iPhone 4.For the iPad, videos must be 1200 x 900 pixels
For the iPhone 5, videos must be 1136 x 640 pixels
Before you start – ingredients
For any act of creativity, be it cooking, or recording an App Preview, you need the right ingredients. For me, I use:
Mac Mini running the latest OS X Yosemite.
iPhone 5 or iPad Air.
Lightning to USB cable.
Quicktime Player application (part of Yosemite) for video capture.
iMovie 10.0.5 for video editing.
Handbrake v0.9.9 x86_64 for final video encoding and cropping.
Capturing the raw video
Apple clearly states that if you install OS X Yosemite, and connect your device via USB cable, you can use the Quicktime Player application to capture the video in it’s rawest format.
This is actually, really easy. Once you have your device (for me either an iPad Air or an iPhone 5s) connected, run Quicktime Player.
If you’re lucky, Quicktime Player will automatically find your device and you’ll see the devices screen pop up in a window on your Mac. If not, from the File menu, select “New Movie Recording”:
This will, if it still doesn’t find your device, open a window that looks like:
Within this, click on the down arrow next to the record button, and ensure that your device is selected. Be sure also to make sure that your device is also selected as the “microphone”. This is important so that any sound your app produces is also recorded along with the video.
Once you’ve done this, you should see your devices screen within a window on your Mac:
So now all you need to do is click on the record button, and then use your app while the Mac records everything you do. Be sure to have a script to follow so that you cover everything you want to show off about your app within your App Preview. Apple has a great podcast within the WWDC 2014 collection that covers this sort of thing.
TIP:
If your app has background music, turn it off before you record your video. It will be much easier to add the music to the edited video later on. In all likelihood you will end up chopping your video up into pieces and rearranging things to make best use of the 30 seconds. When you do this, any sound that is running along in the background also gets chopped up and ruins the continuity of the video. I’ve learnt this the hard way.
Once you’ve finished playing with the app, click on the record button to stop recording.
You then need to save the recording to somewhere suitable from the File menu in Quicktime player.
Editing your video
Now that you have your raw video (I like to name them with the word “raw” in the filename for clarity), you need to edit it, and turn it into a 30 second masterpiece complete with any flashy effects, music or voiceovers. For this, I use iMovie. It’s actually a pretty decent movie editor and I find that I can do most things I need within it. There are other far more capable video editors available, but for me, iMovie works well.
I won’t go into too much detail on how to use iMovie to do the editing, but I’ll address those issues that are important to getting your video ready for iTunes Connect. Here are the basic steps I follow:
Start off, by starting iMovie, and creating a new event for your App Previews.
With the new event selected, click on “Create” button and select “Movie”, and then select “No Theme”.
Click on “Create” and enter an appropriate name for the project. I tend to follow a convention where if my raw file is “Appname Phone raw.mp4”, my iMovie project is called “Appname Phone IM”.
At this point you have a blank time line. Drag your raw video file into this timeline and get creative!
When you’re happy with your 30 seconds of blockbuster video masterpiece (be absolutely certain it’s less than 30 seconds!) it’s time to export the project to a file. Click on “Share”
Next you are prompted to name your video file and select the resolution. For an iPhone 5, it is vital that you select “HD 720P 1280 x 720”. For an iPad, select “HD 1080P (1920 x 1080)”
That is the end of the iMovie phase of the project. You can now close iMovie if you are feeling confident.
Final Step – Encoding and Cropping
As I mentioned earlier on, Apple have very specific requirements about the resolution of the video you upload for an App Preview. To reiterate:
For the iPad, videos must be 1200 x 900 pixels
For the iPhone 5, videos must be 1136 x 640 pixels
So what gives, Apples own tools don’t give us a video that matches these at all! Using Quicktime Player and iMovie we end up with:
1920 x 1200 instead of 1200 x 900, and
1280 x 720 instead of 1136 x 640
Well, as it turns out, the resolution of the iPhone 5 video is almost the exact same aspect ratio as what Apple requires, and we can scale the iPad video such that we get the full height, and then crop the sides to get the exact video resolution we want.
Don’t understand that? Don’t worry, I didn’t at first either; it took me a while to realise that I needed to scale the videos from iMovie to fit what Apple wanted. For the iPhone this is trivial, but for the iPad scaling wasn’t enough because it left ugly black bands down each side. Here is a screenshot of an iPad video I produced in iMovie a week or two ago:
How do we fix this? I use a wonderful tool called HandBrake (http://handbrake.fr). This great application which runs on OS X, Windows and Linux is a free video transcoder. It has a wealth of features and does what we need beautifully.
One great feature of HandBrake is that you can create a “preset” which describes how you want your output to be encoded and sized, and then save that preset for later use. I’ve done this for both the iPhone 5 and iPad App Previews, and this has worked perfectly for me every time.
One huge benefit is that the quality of the final video is great, and it’s also very well compressed. You can probably tune things but for me these presets work.
So, start up HandBrake, and from the “Presets” menu, select import to import the presets I’ve provided below:
Now, drag the video you saved from iMove onto the Handbrake main window (or select it from the “Open” dialog) and you should see all sorts of details about your video:
Note on the side in the Presets “drawer”, I’ve selected iPhone5? This is one of the presets I’ve made available above.
Note also at the bottom where you can see the resolution of the source video (the one from iMovie) and the resolution of the output (what you have to upload to iTunes Connect). The output is exactly what you want.
All you need to do now is click on the “Start” button and wait for HandBrake to tell you it’s finished.
You’re done! You now have a video in the correct format, duration and size for a direct upload to iTunes Connect. Remember that you need to do this with Safari on a Yosemite Mac (as far as I know).
There seem to have been a number of blog posts of late talking about how difficult it is for indie developers to make a sustainable income from their apps. The app store has evolved over the past few years, and not all of us developers have managed to find that pot of gold.
For example, I consider myself an indie developer, though I don’t try, and never have tried to make a living from my apps. Yes, it would be nice to be able to, but I’ve not managed to create any of those app store hits, and I didn’t enter this game early enough to establish my ‘brand’ before the app store became crowded.
With a few exceptions, I’ve focused my attentions on kids educational apps. It’s what I enjoy writing. I know that, even though my apps might not be runaway successes that are loved by all, they are loved by some, and that’s good enough for me. I know that my apps are used regularly by some people; maybe not a lot of people, but by some. I want my kids educational apps to be fun, and helpful; it’s what got me started when I wrote Tap Times Tables.
Early on in this adventure I discovered the Moms With Apps forums where I found other developers. I was looking for help because whilst I knew how to write an app and make it work, I had no idea on how to market it or sell it. I know a lot more now, and that is largely because I found Moms With Apps. The people there, especially the team, headed at the time by Lorraine were so helpful, and through them I discovered “AppFriday”.
“AppFriday” has been, for several years now, an opportunity for developers of kids and family friendly apps to promote their apps at a discount, or for free in attempt to gain more visibility, connect with customers, and hopefully increase sales.
What many of us have found is that AppFriday has been very successful overall, however there has always been an undercurrent of wishing we, as developers didn’t have to mark our apps down so much so that we could not make enough income from them to keep developing. For some time now I’ve tried to avoid setting my apps to free, only doing so when combining it with other promotions, or when I was basically desperate enough for a sale that going free wasn’t going to lose me anything.
Most of the times I set my apps to free, I would see a little kick, but that would only last a day or so. So whilst AppFriday was helpful, it didn’t produce any big sales numbers.
Something that a number of developers have been noticing for a while now is that the number of people turning up for AppFriday has dropped off, and that when an app is set to free, there have been some unusually large educational volume purchases. I can speak for everyone here, but in my case, I set Tap Times Tables to free on the 25th of April. Leading up to that date I was making roughly 1 or 2 educational sales each week. Since that date, I’ve had one single educational sale of Tap Times Tables in the US.
As the images show, educational sales in the US prior to setting the app to free on the 25th of April were a significant proportion of my sales. Since then however that has changed dramatically.
This observation (and I am not the only developer to make it) plus the oft mentioned race to the bottom for prices has led the AppFriday team to try something new. When AppFriday went on hiatus for the Northern Hemisphere summer break, the team sought some feedback from developers on what we wanted to do when the hiatus was over. Did we want to continue with AppFriday in it’s present format (i.e. discount or free promotion only) or did we want to try to try something new?
Well, as I just mentioned, the decision was to try something new. As of the 1st of August 2014, AppFriday has changed to a new format where the only apps that are promoted are apps that meet the guidelines shown at: http://www.appfriday.com/About
Now, instead of promoting discounted apps, we are promoting quality apps that have been Handcrafted for use by kids, that are family friendly, and safe to use. This new emphasis is an attempt to shift the focus of customers so that they will hopefully place some value on the apps that they purchase. We want people to buy our apps because they meet a need; that they are fun, friendly and helpful. Getting people to download something just because it is free or discounted heavily doesn’t encourage buyers to value the apps or what they can do for their kids.
It is also an attempt to return to the days in the app store when you had a new app and actually had a way to let people know it. When many of the developers in the Moms With Apps group began this journey, Apple provided a space in the “New and noteworthy” area of the app store. This gave customers a way to see the new apps, regardless of who published them.
The “Best New …” area in the app store these days is not actually a list of “new” at all; it’s a curated list of what is selling well. Sometimes there are new apps in there; but most of the time the apps there are not actually new. People like to see new, shiny things on the shelf; even if it’s just to take a look and consider whether they want it. This new AppFriday is our effort to give you a new way to find the new apps, and the freshly updated apps for your family and your kids.
So this Friday, when you see developers and other people on Twitter using the #appfriday hashtag, take a real look at the apps. See if there is something you need. Are your kids struggling with their Times Tables? Do they need help with spelling? Do they need a fun distraction like colouring in, or playing with concepts such as recycling, body parts, reading, etc?
And, if you do purchase an app, and you like it, don’t be afraid to pop into the App Store and post a review to let the developer know. Reviews make a big difference. Even if you don’t like something about an app, the developers would love to hear from you via email (most of us provide links to support sites).
Today I came across the following info graphic. As I continue to work on new educational apps (the current one is coming along nicely), I’m very aware of the need to try and make the apps useful for all kids. Through my apps, I’ve come in contact with a number of people over time that work with or have kids with special needs.
This info graphic seems quite timely, as my next two apps (after the current one) will be developed especially for kids with special needs, in cooperation with a group of teachers that work in this area. I’m really quite keen to start on those projects as they represent a real need.
Here is the info graphic. I’m not associated with it’s author at all, but if you want to contact her, the website is:
At the moment, she’s working with my original MacBook, a 2009 white unibody MacBook which, as can be seen, has had better days. It still works a charm, though it’s been running hot, with all fans howling for a year or two now.
Apple are basically saying to me, “Hey Peter, we understand you can’t afford our sparkly new Touch Bar MacBooks, but you can always buy the new MacBook Pro without the Touch Bar. It’s only $2199!“.
