Category Archives: Coding

Stripping print and debugPrint in Swift for release builds

When building an app for release with Swift you should make sure that any of the print and debugPrint statements you used when building and debugging the app are disabled.  The reason for this is that if you leave them in then they will unnecessarily slow down the app since every write to console output takes time.

In Swift you can easily do this by redeclaring the print and debugPrint functions using these two lines of code…

func debugPrint(items: Any..., separator: String = " ", terminator: String = "\n") {}

func print(items: Any..., separator: String = " ", terminator: String = "\n") {}

We simply declare the functions again but with empty implementations of {}.  When you’re building and testing your app just comment these two lines, but when complete make sure you uncomment them before release.

You should place these two lines at the top-level of your code.  That means, do not put it inside a class, extension or protocol declaration.  A good place to put them is at the top of your AppDelegate file, before the AppDelegate class and not inside it.

Alternatively, simply create a brand new Swift file in your project and call it something like ‘ReleasePrint.swift’ and put the code in there.  Basically, it can be anywhere as long as it is top-level and not inside another class.

Finally, you may find it useful to always see the output from print and debugPrint in the simulator, but never on the device.  If you want to do this you can use the architecture flags to automatically turn the output on and off as follows…

#if !arch(x86_64) && !arch(i386)

func debugPrint(items: Any..., separator: String = " ", terminator: String = "\n") {}
func print(items: Any..., separator: String = " ", terminator: String = "\n") {}

#endif

WiFiFoFum Intrepid

I’ve been working on a new version of WiFiFoFum with Malc.  The codename we’ve used for the project is Intrepid, and it’s basically a complete rewrite of the WFFF codebase to get it compatible with iOS 7.

As many of you will know, WFFF for iOS has languished for some time due to Apple’s policies around Wi-Fi scanning.  Years ago WFFF was kicked out of the official App Store and we subsequently put it in Cydia.  Although it found an audience in Cydia, it got harder and harder to develop the app when Apple were not only denying us access to the iTunes Store distribution channel, but also seemed to be doing everything they could to block developers from accessing the Wi-Fi functions in iOS devices.

Dynamically Loaded felt it was time to try to push the boundaries again and, thanks to some simply stunning and ground-breaking work from Malc, he and I have created a version of WFFF that works wonderfully on standard iOS 7 devices… no jailbreak required!

I’m particularly proud of Intrepid.  A decade ago Malc and I were the first to figure out Wi-Fi scanning on Windows Mobile devices, and released WFFF as the world’s first widely available, mobile wireless scanner.  Half a decade ago we were the first to discover how to achieve Wi-Fi scanning on the iPhone, which led to the first iOS version of WFFF.  When Apple changed the Wi-Fi frameworks a couple of years later we again were the first to discover how to scan using new techniques.  Finally, when Apple completely removed Wi-Fi access via the iOS frameworks, even when using the hidden techniques we had discovered, I thought we’d never again be able to provide Wi-Fi scanning on jailed iOS devices.  However, with Intrepid we’ve done it, and I can’t wait to release it publicly and make the world’s best Wi-Fi scanner available to all iOS devices once more.

Our new scanning methods do not break ANY of the iTunes App Store rules so we will be submitting it to Apple and hope to have WiFiFoFum Intrepid available through the official store.  However, there are never any guarantees with Apple, so if for any reason they do not allow it into the store we will be making it available directly through the Dynamically Loaded site.

Intrepid will be ready for release soon, but in the meantime here are some screenshots of it running on my own jailed iPhone 5.

Native versus HTML 5

As a developer who primarily writes natively for mobile platforms, I frequently get asked about native code versus HTML 5. Obviously, this happens most when people want to hit multiple platforms. They speak to developers who advise them that they’ll need to hit say at least iOS and Android, and then they’ll respond with something along the lines of “well, I’ve heard HTML5 runs on all devices, so I’ll just do that since it’ll be cheaper and then just work on everything”.

This issue has been reported in the mainstream media yesterday, as Mark Zuckerberg has publicly stated that using HTML5 on mobile devices was ‘the biggest strategic mistake we’ve ever made’, and that ‘it was really painful, we were never able to get the quality we wanted’. If Facebook had asked me 2 years ago when they started developing their mobile app, I couldn’t have more strongly advised against using HTML5. In some sense I can understand why Zuckerberg would make the choice he did though. He wrote Facebook initially using HTML, PHP and Javascript, that’s where he logged all of his coding hours. His experience of coding has all been web-based, and that is what he understands and is comfortable with.

As a developer who understands mobile platforms, it often grates on me when people view HTML5 as a viable solution in that space simply because they hear that it ‘works everywhere’ and flashing lights go off in their head as they suddenly see cost savings. There are a plethora of problems and issues that arise when mobile solutions are attempted with HTML5. Unfortunately, most non-techies, who are making the decisions, simply don’t understand the repercussions.

Note that when I talk about an ‘HTML5 app’ I mean an app that has a native shell that provides a standard web view, and then the majority of the app works inside that web view.

Firstly, HTML5 will always result in a slower and clunkier interface than native. For one, the app has to hit some server online that is hosting the HTML so there is the initial overhead of retrieving this. Whilst this may seem fast for one off operations, let’s say as an example one second, you have to remember that any serious use of your app is going to involve hundreds or thousands of these requests.  Waiting one second once is okay, waiting one second a thousand times is not. Note that in computing terms 1 second may as well be eternity, most native operations will be measured in pico or nano seconds. Once the HTML data has been received from the server, it still has to be decoded, interpreted and then the web browser has to conduct the appropriate work to update the display. All of these tasks are out of your control, you are relying on the browser to do this efficiently. Indeed, all of this assumes the user has a good Internet connection and the servers are working 100% of the time. If either of these aren’t true then an HTML5 app can fail in horrible ways, displaying blank or 404 pages.

Another issue is that an HTML5 app will never be able to make full use of the a mobile device’s capabilities; they are stuck with what HTML supports. Mobile devices are evolving from one month to the next, with better cameras, accelerometers, GPS, NFC… a never-ending multitude of sensors and capabilities, all of which are immediately supported natively.  However, HTML apps can’t access most of these, and if they can then they can only do so when support is eventually added and even then only in very specific and inflexible ways. For example, even though GPS hardware has been around for a long time and is in nearly every mobile device now, with HTML you might be able to get a location from the GPS, but you have to ask for it in a specific way. You can’t get rapid location updates, and you can pretty much forget about retrieving any other interesting information the GPS and location hardware can provide, such as altitude, speed, heading. Even forgetting the hardware and its sensors, HTML 5 apps can’t make full use of the excellent native APIs that most platforms provide. For example, on the iPhone there are APIs for sharing items via email, Twitter and Facebook. Users see these standard sharing items everywhere, and become familiar and efficient with them. These standard widgets are designed by the device manufacturers to be beautiful, and present information clearly in an easily understandable.  Yet HTML 5 apps are unable to use these, and will instead fall back to embedding features like sharing in the web view they operate within, the text will likely be small, and users will be forced to slowly figure out this new method whilst becoming increasingly frustrated as they strain to read the small text.

HTML5 apps also tend to really stick out, in a bad way, because they are unable to conform to the HIG (Human Interface Guidelines) of the device. Nearly all devices come with a set of guidelines about how developers should design and implement apps. These include things like how big buttons should be, how tables should be laid out, how information should be presented using standard widgets, etc.  Again, HTML5 apps can’t access these standard widgets that all other apps can.  They may try to duplicate them, but the duplication never quite looks right, and even if it is a good visual facsimile, when the user interacts with them they will be slow or jerky.  Basically, just as some human-looking robots fall into the uncanny valley and end up making people feel nauseous, these HTML attempts to copy end up doing the same for graphical widgets. Users look at them and expect one thing, and then become annoyed and frustrated when they behave oddly.

A final issue with HTML5 apps is that the primary claim of them working everywhere, across all devices, is just plain lies. Every device and operating system interprets HTML slightly differently.  You just have to try any HTML compliance tester (e.g. http://html5test.com) from multiple browsers to see for yourself how different the same HTML can be from one device or browser to another. The standard mobile browsers provided in Android, iOS and Windows Phone are all wildly different, and you can never be sure that the design you are supplying will always look or work the way you intended.  Add in screen size differences (tablet versus phone) and you end up with so many combinations that you can be certain that your HTML5 won’t be looking and working as you expected on at least some devices.

So, my list of HTML5 app problems are:

  • Always going to be slower than native
  • App may fail if servers go down, or connection is not available
  • Unable to use the full features of the device/OS
  • Unable to conform to the UX/UI guidelines of the platform
  • Actually not as compatible as you may think

In short, if you know for sure that you’ll never want to use any of the unique features and functionality that is currently available on mobile devices or that may come along in the future; don’t mind a slow, ugly, non-standard app; and truly believe that by some unknown magic HTML5 looks the same on all platforms and screen sizes; then sure, maybe HTML5 is a good solution for you.

Seriously though, don’t be fooled by the one claim that HTML5 relies on… that it just ‘works everywhere’.  It doesn’t.  Apps represent your company and your brand, they are a direct channel to customers. HTML is an ugly, slow and hacked together solution; don’t force that on your customers.

How to handle ‘No previous prototype for function’ warnings in Xcode

When compiling code in Xcode 4 you may be seeing warnings saying ‘No previous prototype for function…’.  This is probably happening if you are using a library that has at least some parts written in C/C++.  This warning may even be appearing in code that previously compiled fine in Xcode 3 without any warnings.  This is because Xcode 4’s default compiler warns about this when Xcode 3’s did not.

Anyway, the warning is simply saying that a function implementation exists but no matching function declaration was found.  If you are used to Objective-C only this is like saying that you have the implemented code in the .m file but you don’t have the function listed in the .h.  It’s easy to fix, just write the method declaration in anywhere before the actual method; you can write it in the .m or .h, it won’t matter as long as it’s before the actual function.

For example, if you have a method such as…

float doSimpleMaths(float a, float b) {
   return (a*a)*(b*b);
}

Then to get rid of the warning just add in the method declaration before the method…

float doSimpleMaths(float a, float b);
float doSimpleMaths(float a, float b) {
   return (a*a)*(b*b);
}