Well I just finished rolling back all my new iOS features (images and custom masks) into OSX and generally cleaned up the code. I also did a lot of work extending my testing coverage over more of the core functionality after using XCode’s new code coverage feature.

Above you see my SCRUM Board, currently clear after finally consolidating the iOS app fully into my master source branch. I like having the board even though I work alone at home, it helps me to break down jobs and makes me think about exactly what each version will contain. It’s also a good reminder to work on the project.

TBH though, as it’s just me, I can get a little lax, I’ll put one note down for a new feature that’s actually about ten individual tasks for example, or I’ll suddenly start refactoring a huge bunch of code just to make one task simpler. The scrum board helps keep it all under control, especially for things like feature creep. As a sole developer, it’s quite hard to decide what features to include in an app for any release. You keeping getting ideas for new features and updates, and as you work on an app of your own making, it’s very tempting to just start working them in, pushing a final product or release ever back. Taking time to plan what you have for each release, making up all the tasks and laying them out on a board makes the whole thing look a lot more manageable. New features and updates can be put aside while still being considered in the coding of the current release.

I’m updating Unit Testing for the next OSX release and see a couple of new features in XCode.

Testing code coverage is nice, it was available before, but wasn’t the easiest to implement. It’s now built in and can be turned on from the Schemes editor, and reports turn up under the reports tab.

The actual code coverage report could be presented better, there doesn’t seem to be any order to it. My coverage isn’t too bad on the underlying model and rendering facilities, but I see some stuff I’ve missed. It also shows classes that I’ve forgotten altogether, while a couple are things I’ve overlooked or put off, A lot of them are to do with my User Interface.

Which brings me to the next added feature in XCode, UI testing. I know there are companies that provide UI testing for xcode, I didn’t see a free one… So I’d been testing manually, but finally it’s been added to XCode 7. I’ll be looking at implementing that too in the future if it looks like it’ll work.

I’m currently porting some features of the iOS version of the Reality Augmenter back into OSX. This includes the ability to load images, and use custom masks made from any of source types.

So no longer will you be limited to the circle mask for projection mapping in OSX, you’ll be able to use videos, images and quartz compositions to mask your mapped areas.

Next release should be very soon, just tidying up a few odds and ends and need to make sure testing is up to date.

My iOS app got approved and is now available for sale! I’ll be updating the web site today.

So chuffed with that, there’ll be plenty more updates to come!

Apple wanted a demo video as part of the review, knocked a quick one up yesterday, it takes you on a walk through of the app’s capabilities and shows how the projection mapping is done.

I’ll need to make a professional looking one at some point.

Got rejected, but not because of the Binary, that’s good, they want a video of how to use it for the review, so I’m busy making that today. I was a bit scared they’d reject it straight away as the application is a little unusual for an iOS device, I was worried the fact it does nothing without a projector connected would just get it instantly rejected, but asking me for a video on how it’s used is encouraging.

After a busy couple of weeks, I finished up the iOS app and it’s now been submitted for review, it’s my first app submission, so let’s see how it goes…

As well as adding the dev blog, some new changes will be coming to prepare for the iOS release of the Reality Augmenter.

Currently putting the finishing touches to the iOS version of the Reality Augmenter. It’s pretty much feature complete and reliable, just tweaking the user interface and adding final touches.

It’s taken a lot to get here, I wanted to share as much of the code as possible with the OSX version. I’d already stuck to an MVC design pattern which meant most of the iOS work was re-building the view aspect, and rethinking how that would work in an iOS environment. I found the storyboards very easy to pick up and good way to work, and once I’d got the hang of tab and navigation controllers, the basic app built up very quickly.

On the controller side, I’d implemented quite a few things in NSArrayControllers, which aren’t available in iOS, but there wasn’t too much going on in them so could implement some shared classes between iOS and OSX that plugged into the original array controllers and provided the functionality I needed in iOS.

The toughest part was upgrading openGL. Originally the OSX version used a legacy profile because of the Quartz Composer functionality. While there is a fixed function pipeline in ES1, I really wanted to be able to use later versions of ES, which meant upgrading the original to core profile. This means practically all of the openGL code is shared between OSX and iOS, with only different shaders supporting the differences between core and ES. I could probably work on a shader compiler to further reduce differences, but for now I just have different shaders for different versions.

Of course, now there is Metal, and Swift has been taking off too. Once I complete the iOS version, and migrate it’s new features into the OSX version, I’ll be looking to switch the code base over to Swift and Metal.