Back in the 1980’s, when I used to spend way too much time playing games on my Apple IIGS (and earlier, my Apple IIe), one of my favourite games was Fortress, by SSI.

Fortress gave me a small game board where I would fight it out against one of several computer AI’s, where a game consisted of 21 turns, and whoever controlled most of the game board at the end was the winner.

One of the things I loved about Fortress was the way the AI’s got smarter with time. When you first started playing, it was easy to win, but after a few games, it became more challenging. This kept me coming back to Fortress as I felt I was playing against something that basically learnt as I did.

As a programmer/developer, my mind is rarely idle, and I always have a project on the go. In the 1994 I thought it would be neat to rewrite Fortress for the Apple IIGS, using higher resolution graphics.

I started doing this with the ORCA/Modula-2, which I had recently brought to the Apple IIGS with publishing help from The Byte Works and some connections at Apple.

As part of writing this blog post, I’ve run up my Apple IIGS environment (yes, I still have all of it) within the wonderful Sweet16 emulator and found that code:

I hadn’t realised just how much of the game I had written. I thought I’d only written a bit of the game logic, however it turns out I’d written a lot of the UI as well, as can be seen from when I ran it. The AI’s hadn’t been written but the basic building blocks were there.

The funny thing is, I have the code; I have a compiled binary that I can run, but I can’t remember how to re-compile the source code anymore. I’ve got a build script there, but my memory fails to help me out.

One of these days I should bring all that code out, and store it somewhere safer.

Around this time, I got distracted and much of my home based projects took a back seat, Fortress included. My work took me away from Apple development entirely for around 15 years.

So Fortress GS was left on a floppy disk (or two) in a box of backup floppies along with everything else.

Then, in 2012, after I’d been back developing for Apple hardware again for a few years I got the bug again, and, having recovered my entire Apple IIGS development environment from hundreds of floppies and some second hand SCSI drives (my how they’ve grown; did you notice the size of the “M2” hard drive above?), I was able revisit Fortress GS.

I ported the guts of the code to Objective-C and wrote a basic prototype to show to another developer at the time as a proof of concept. This one was really basic, but it allowed me to place moves for both sides by tapping the screen.

I showed this to a designer I knew at the time who thought the idea was great, but suggested that it would be more interesting with a hexagonal grid rather than the rectangular one.

I toyed with the idea at the time, but I did nothing with it; I had other projects happening, and I wanted to focus on my educational apps.

Moving up to 2016, and the release of the Apple TV, I launched my latest educational app, Tap Tangram (which I later launched as Classroom Math Drills), and due in part to my failure to recognise that I’d missed my target, and the complete lack of featuring by Apple, the app never gained any traction and failed at launch.

That left me wondering what to do next, and then it occurred to me to reboot the Fortress app idea once again. I’d also recently read a most-excellent blog article by @redblobgames about manipulating hex grids in software, so my mind was abuzz with what I could do with it.

Enter World of Hex, my latest, and final attempt to reimagine the classic Fortress for iOS and the Apple TV.

I started out just playing with the hexagonal grids code that I wrote as a port of the code provided by @redblobgames and getting the basic board working with the underlying move computations.

Once I’d done that, I sat down and brainstormed how I wanted the app to work; how the game would play and during this process, I asked myself:

“What if, rather than a simple rectangular grid of cells, we had a map of the world as a map of hexes?”

And then I got going.

“What if, the terrain was somehow represented in this 2D map of hexes. Rather than try to represent the 3rd dimension as a true 3rd dimension, colour the hexes to represent the terrain.”

and

“Hmm. how many cells?”

“Earths land surface area: 150,000,000 km2”

“If we say each hex has a real world “size” of 1km, then we need to be able to map out 150 million hexes eventually. Even if they aren’t all being used by players, we need a way to know where on the earth a hex maps to land.”

“So, what is probably easier, is to map the entire planet with hexes, and then mark some as usable land, and others as ocean, unusable land, etc. that means a lot more hexes in the database though. It means millions of hexes to cover the planet completely. too many.”

“Will performance be an issue? yes.”

And so it went; with performance an issue and no real idea at that point of how to make it all happen I went hunting for others that had build a world of hexes. I needed to get an idea of:

Could I get the basic mechanism to work on an iPhone

How many hex tiles would I need to build a reasonable approximation of the Earths land areas?

How would it perform if I built a model with all those tiles?

After some searching with Google, I happened upon the wonderful Hexasphere.js by Rob Scanlon. This gave me hope. If this could be done in a browser, then I could do it.

So I set about to port his Hexasphere javascript code to Objective-C to see what I could achieve.

This is where I started to hit upon the boundaries of my knowledge of 3D modelling and SceneKit. I also found myself struggling with some of the math concepts involved, having to trust in these people that obviously handle it better than I.

I did get Hexasphere working, though it was extremely slow because every hexagonal tile was being implemented as a separate SceneKit node. It did work, but it just wasn’t going to cut it for a production quality game. At this point I was using very large hexagonal tiles, so the tie count was still quite low. Once I increased the resolution of the model, there would be a lot more.

I ended up posting a question or two on the Apple developer forums and the Games Stack Exchange. These helped me better understand how to improve the performance of my 3D model however I was still hitting problems in that the on-screen representation of the Hexasphere was not high enough quality.

I spent several weeks working on it and getting some great help from colleagues who knew math, and 3D rendering far better than I. The end result of that was a perfectly rendered Hexasphere using only 4 SceneKit nodes that rendered at a full 60fps on devices as old as the iPad2. The change was to put all of those tiles into a single model, and to colour them individually via the shader and it’s inputs.

I finally had what I needed to get on with the game.

At this point it was just a matter of bringing all of the pieces of the puzzle together and making them work well.

For this game, the main pieces were:

The hexasphere code

The Hex Grid code

SceneKit and SpriteKit

CloudKit (iCloud based database)

I’ve already spent enough time on the hexasphere and hex grid, so I’ll try to restrict the rest of this post to the hurdles I had finishing off the app and bringing it all together.

SceneKit and SpriteKit

Apple’s engineers have done a wonderful job of these two API’s. Having developed most of my apps with Cocos2D, the transition to SpriteKit and SceneKit was pretty painless. The primary difference for me was the coordinate system.

The main reasons I went with Apple’s frameworks this time were:

I wanted to be able to render the 3D world, which Cocos2D wouldn’t do.

I also wanted to branch out and learn something new.

That said, the trick was that I needed to be able to overlay my 2D game components on top of the 3D components. After a little research I discovered that Apple had kindly given us an “easy” way to do this via the overlaySKScene property of the SCNView class.

This works remarkably well however it does introduce some problems because there are bugs in the Apple frameworks (at least, there are at the time I write this). I found that there are some things, like animations of the SpriteKit nodes that need to be forced to be done within the SceneKit renderer thread. It seems that Apple use a multi-threaded renderer for SceneKit/SpriteKit and some operations that you’d expect to be thread safe, aren’t.

With a lot of help from Apple Developer Technical Support, I found and fixed this problem and filed a bug report #32015449 (github project) accordingly.

Another issue related directly to the use of overlaySKSCene was an incompatibility with the tvOS focus engine (it basically doesn’t work). I ended up having to port a focus engine I’d written for Cocos2D on tvOS and enhance it to work with World of Hex. I’ve also filed a bug report for this issue: #30628989 (github project).

Apart from this, SceneKit and SpriteKit work a treat and have made my life so much easier.

CloudKit and iCloud Integration

Once I’d decided to expand the original game beyond a single game board, and to allow people to play games in a world of game boards I needed a way to store the game boards in the cloud so that everyone sees the same thing.

When I started to develop this idea my family and I were enjoying Pokemon GO for the novelty it provided. As a user, one of the things I really didn’t like about Pokemon GO was the way it forced users to either associate our existing Google account with the app, or to create a brand new Google account just for the game. There were other options, but they all involved forcing the user to log into a specific account, just for the game.

So I looked at Apple’s CloudKit which is just one part of the whole iCloud service layer that Apple has been building and developing for years now. One of the beauties of CloudKit is that for every person using an iPhone or iPad that is logged into iCloud, an app integrating CloudKit will just work because there’s no explicit login required.

This is what I wanted. On the whole, the CloudKit integration was very straight forward and it does just work.

I really enjoyed the ease with which Apple have allowed us to define our database structure via the CloudKit dashboard, make changes and even migrate those changes from development to production environments painlessly.

If there is one thing that I found lacking it is that in the dashboard, there is no way to simply remove all existing data without also wiping the database model itself.

Conclusion

World of Hex has grown far beyond what I originally set out to write. It’s nothing like my original attempt back in 1994 on the Apple IIGS, and even my really early brainstorming of last year differs somewhat from what I’ve built.

One of the reasons I build these apps is for the challenge and to keep my active mind busy. I certainly don’t make much of an income from them (though, mind you, I wouldn’t complain), so there’s a lot of satisfaction in having an idea realised and released into the world. Yes it can be crushing when it doesn’t take off, but, as I mention in the credits scene within World of Hex (can you find it?), “Never Give Up”.

Learning some of the quirks of Apple’s frameworks has certainly been a challenge. Cocos2D has been wonderful to work with over the years, and in some ways it’s more mature and easier to work with than SpriteKit, however SpriteKit’s deep integration is hard to pass up now that I’ve learnt it.

SceneKit offers some pretty amazing functionality from my point of view. I remember, as a teenager back in the early 80’s having a book with some algorithms for 3D line art animation that blew me away at the time. Being able to draw a model in your fave modelling tool, drop it into Xcode and have it on a device screen in minutes is insanely great. For developers out there that think its tough work creating an app, you have no idea how spoilt you are.

If you’ve read through all this, then thanks for staying till the end. It grew somewhat longer than I’d planned.

Here it is, my World of Hex. I hope you take the time to have a game, and that you enjoy it.

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.

Video Creation

Game Centre integration is on the way out for two of the PKCLsoft apps.

Today, updates for both Tap Times Tables and Math Plus Minus were rejected by Apple.

The reasons given were that both apps have links that can take the user out of the app. With the new “Kids” category that is coming out with iOS 7, any apps that want to be included in that area have to meet new, tighter rules.

One of those rules is that your app can’t have links that take the user (the kid) out of the app, unless there is a “gate” that can typically only be opened by a parent or adult.

As the kind people at momswithapps.com have pointed out here, there are different ways to implement a “gate”.

Now I can understand where Apple is coming from, so I’m acting accordingly. I’m removing Game Centre from both apps completely.

I don’t want to leave it in and put a “gate” there because it just doesn’t make sense from the kids point of view. If all s/he wants to do is look at his score, then asking for a parent to open the gate doesn’t make sense; it’s unwieldy.

So, the question I asked myself (and this was also asked in a way by Lorraine at momswithapps.com): “Does Game Centre really add any value to the apps?“

When I look at the apps in Game Centre, the number of players is only a small proportion of the total number of people that have downloaded the apps so perhaps it’s not such an important thing.

Encouraged by this, and also driven by the need to correct the issues for Apple, I’ve acted to remove Game Centre.

If you use either of these apps, and are upset by this, please let me know. If there is enough demand, I can look into adding it back in, in the future, and add a gate.

Wow, it’s been 9 months since my last post, and so much has happened since then. It’s been so busy, and I find myself so caught up in keeping track of other sites like my facebook page, the Parents with Apps forum (a ‘child’ of Moms with apps), various review sites, and promotions such as the AppyBack2School even being run throughout August by the Technology in (Spl) Education website.

This all started out as a hobby for me. I wanted to keep my hand in some contemporary development, and I’ve always loved working with Apple products (and that goes back more years than I care to admit).

After my last post, back in October 2011, I came to the realisation that kids are getting through primary school without learning some basic skills. I went to a parent information evening at the school which turned out to be all about parents needing to help their kids with their math skills. Kids entering this school at Year 7 come from all over, and the range of abilities/knowledge was apparently quite diverse.

So I set out to write what was going to be a simple Times Tables app to do my bit. My kids were not having any trouble, but it highlighted to me that there was a need. Looking at the app store, I could see that there was plenty of competition, but it seemed that there was still room to move as people seemed to want something more.

Thus, Tap Times Tables was created over the next month or so. Both of my kids got involved with it’s design and interaction, and whilst it hasn’t broken any records, it’s done OK, certainly better than I had expected given the flooded market.

Soon after it’s release, I was asked to write a similar app for addition and subtraction, and Math Plus Minus is the result.

So, for the next little bit, leading up to the end of the Australian school year, both apps were out there, and were quite a celebration of having done something positive. I could see that the apps were being used on a daily basis, and from some of the feedback emails I was receiving, I could also see that they were being used within school environments.

Then the school holidays hit, and sales took a bit of a dive. Even today, although I have never specifically targeted Australia, my sales here have far outweighed those overseas. Not having any sort of marketing ability, I just accepted it and waited for school to go back.

Now, recently, the northern hemisphere has gone on holidays, and it seems that the entire education app developer community is spending a great deal of time trying to keep the sales happening during the break.

I’ve been so busy with new app development on the side that I’ve not had time to join in the marketing in the way I probably should have.

In an attempt to rectify this, I’ve shelved my other app work and am currently adding some really great features to both math apps that will make them far more useful in a classroom environment. My hope was to have these released by the 1st of August to coincide with the AppyBack2School promotion during August, but I’m running behind.

What have I been doing? Well, to start with I’ve added the ability for a teacher to, via a Google Docs spreadsheet, enter a roster of student names for an entire year level and import this into the apps. This means that for a school which has a bank of iPads or iPod Touches with my apps installed, they can hand them out to students and allow the students to use the apps, recording their results against their name, and reporting it back to a teacher via email.

A sample spreadsheet for this would look like the following:

In this example, we have a roster for Grade 4, comprising 4 classes of students where the name of each class includes the name of the teacher.

In addition to this, I’ve added the ability to create a lesson. Each lesson consists of one or more questions that can be played in the main game of the app. The beauty of this is that the teacher can now take control of what questions the students are answering. They can even specify what incorrect answers will be shown so that all students are presented with the same options on screen (thus levelling the play field).

Combining this with the roster, it becomes easy for the teacher to distribute a “test” to students within the app that they can sit, and then submit results for.

An example lesson for Tap Times Tables is:

In this example, we have 12 questions for a lesson called “Mixed tables”.

I’m really pleased with these changes to the apps, as they really represent a move from being what started out as “simple” learning aids, to becoming real classroom aware tools.

It is my sincere hope that with the beginning of the school year in the northern hemisphere, my efforts within the apps, and the efforts of people like Siva at Technology in (Spl) Education that I’ll see the apps being used more and more.

I never went into this to get rich (although my family wouldn’t mind), but if I can bask in the inner glow of knowing I’ve helped some kids out, and made a little on the side as I do then that would be great.

A friendly user has noted that my optimizer tool was being a little severe. Any menus created within iWeb with rollovers would end up not working after optimization because the rollover images were being optimized, placing them where the javascript Apple provides can’t find them.

A few days back, uAlertMe v1.2 hit the app store. This version added a browse function for setting up a bonjour connection to your Mac, plus a history of location in the map view. It also fixed a number of issues relating to the way uAlertMe stored images in your camera roll.

Since the release of v1.2, I’ve noticed a small (<10) number of crashes from the new version that seem to be happening when people try to use the new browse feature. I haven't been able to reproduce them here, no matter what I do, but I think I can see what might be happening.

To this end, I’ve submitted v1.3 to the app store, which I’m hoping will address these issues.

If you are having trouble with uAlertMe, please use the support email address (support@pkclsoft.com) so that you can let me know what you were doing when you had the problem.

Likewise, if there are features you’d like to see, email me or post your suggestions here.

It’s done. I’ve just finished updating the webpages for uAlertMe, having submitted v1.2 to Apple tonight.

v1.2 brings with it a number of corrections that should address some stability issues that people may have been experiencing, especially on older versions of iOS, or on devices with large videos in their camera roll.

v1.2 also adds two new features:

When a location is sent to uAlertMe, it is now kept as part of a history, unless it is the same as a previous location. This way, you can see a history in the map view, of where your Macbook has reported it’s alarm going off. As a part of this, the annotations that popup when you tap a pin, now sport a button (right arrow) that allows you to navigate through the history, and an iAlertU icon that when tapped will retrieve the photo taken by your Macbook when the location was reported.

These pins may be deleted from the options screen if you desire.

Some people reported that it’s too hard to configure. As a step to help out with this, I’ve added a browse button next to the hostname field. Tapping this will cause uAlertMe to scan the local network for any Macbooks running iAlertU that have their internal server running, and configured to use Bonjour.

Any Macbooks found will be listed in a picker for you to choose from. If there’s only one, then it will automatically be put into the hostname field for you.

I hope that this version of uAlertMe proves to be more stable for those of you having had problems.

If you like uAlertMe, please review it in the app store. If you have problems, please, before you make a negative review online, contact me and I’ll try to help. As some people know by now, I’m very responsive to help requestes.

When I first started on this game I thought it would be a simple matter of taking the ‘golf’ code and applying new photos, and a few changes to images.

Footy is a very different game to Golf in the real world, and this translated into the iPhone world as well, even with these game. What was originally going to be a simple task took on new life as the scoring, animation, game play, and general behaviour of the game changed to suit football as a game whilst still maintaining the original concept.

One simple example of this is the shape of the ball. A golf ball is spherical, and as a result it’s easy to wrap a texture around it to get a nice animation of the ball. No such luck with a football. I had to find a way to respect the shape of the ball, move it around the screen, and still use it effectively.

OK, so as I’ve said previously, version 1.1 of uAlertMe added support for Push Notifications. All it needed was for iAlertU on the Mac to send them

Last night I released v0.74 of iAlertU which adds the required functionality for all of this to work.

Getting all this to happen was actually not all that hard; Apple have made it fairly easy for us.

Originally, iAlertU was going to act as the actual provider, connecting to Apple’s APNs directly. I had the whole thing working, with the entire push notification provider written in Objective-c.

The only problem was that doing it this way meant including my private certificate for the SSL connection to Apple in the iAlertU bundle. This as my conscious and several helpful souls pointed out was a great way to ask for trouble if someone decided to misuse that certificate (although I had gone to some lengths to make this harder).

So, the next step was to add to the pkclSoft web server a provider that iAlertU could then interface with. This all looked too easy as there is a great package called easyapns that does just this, and it would have worked fine except for one thing. My web host blocks outgoing connections on the ports that Apple use for connections to their servers.

This effectively killed my ability to use easyapns which was a shame, but there were other options in the form of Push service providers.

The first I looked at was UrbanAirship. They looked great, but there is a potential cost as only the first million pushes per month are free. Although I thought it unlikely that the users of iAlertU would end up using more than this, I didn’t want to take the risk; after all I get nothing for my time on iAlertU, and uAlertMe doesn’t do well enough to pay any bills.

So I looked for another alternative, and found Xtify who offer a straight out free service to developers. I then set out to spend the next couple of days getting iAlertU to talk to Xtify, but found that whilst their service was great, and the customer support was excellent, being able to send a notification payload that could be localised by uAlertMe so that the notification can be displayed in the appropriate language was too hard. Basically, Xtify get you to send a payload in their format that is then translated into Apple’s format. This just wouldn’t work.

Back to UrbanAirship for me. Whilst they do something similar (so that you can send a single push to both iOS and Android devices) to Xtify, their interface is much more natural, better documented, and supported by packages of code that are easily obtainable via their website.

What about that cost-risk? We’ll I’ve decided to test the waters so-to-speak. I figure that with only a few thousand users out there, and that normally, the only time the push will happen is when the alarm goes off, people would have to be triggering their alarms hundreds of times per month. Given what iAlertU is, I don’t see this as likely.

We’ll see I guess. I’ve read blogs where people have bemoaned the cost of push notifications. If there does turn out to be a cost, then I’ll revisit how it’s done.

I hope to get my original objective-c push provider into somewhere like github soonish. Let me know if this is of interest.

For now, I’ll keep an eye on UrbanAirship, and hope that everyone finds the new functionality helpful.