We are thrilled to announce some groundbreaking work we have been doing with Telstra for Google Glass. Over the past six months we have developed two world-first Google Glass apps designed for the visually and
What a proud day for the b2cloud team. We have just been announced by the Deloitte Tech Fast 500 Asia Pacific as the 14th fastest growing technology company in the region, and the fastest growing mobile app developer.
Over the last 4 months b2cloud has been busily building Google Glass Apps for the most forward thinking companies in Australia. Not to mention the neat little Apps we have developed for demonstration at events around Australia including Glass Tabs – Learning guitar through Google Glass.
When you send a build to your client or testers, it can be difficult telling development builds from AppStore builds. At b2cloud we split the builds with two different app ids, and a different app title to make it easy to tell them apart. Because the app id is different it means you can have both builds on your device at the same time, and the development one wont overwrite the AppStore one, and vice versa.
Following on from last week’s blog, this will cover monitoring an iPhone’s HTTPS traffic. If you haven’t already, look at the setup from last week as it is required in order for this next part to work.
Previously when I’ve needed to monitor web traffic from my iPhone I would use my laptop to redistribute my wifi as a 2nd network with another network card and use a tool like WireShark or Charles to monitor everything that’s being sent and received from my iPhone after I connected to the 2nd network. This was overcomplicating things, hidden in the iPhone’s settings is the ability to connect to a proxy server, meaning you can debug web traffic without the need for any 2nd networks or ethernet cables.
Since Xcode 4.1 when your application throws an exception your console just prints a list of function pointers and you don’t get a proper stack trace. This isn’t helpful if you’re trying to find the exact line the error occurred on.
If you have ever needed to store a password or other sensitive data in an iPhone app, you have probably used Keychain Access, Apple’s solution to storing data securely. You have also probably used Apple’s KeychainWrapper class, offering a very easy wrapper to storing info in the keychain.
The KeychainWrapper worked well in debug mode, but when building for release it didn’t seem to be writing objects to the keychain. I was fumbling around with this for hours, going over my own code thinking I had made a mistake somewhere. In the end I figured out what the problem was, in Apple’s code for KeychainWrapper the actual line that executed the commit to the keychain was inside an NSAssert, which is used for development, but as soon as you build for release or distribution every NSAssert is nullified, giving the same effect of commenting out anything on that line, removing the keychain commit code.