Effective problem solving requires that you fully understand the problem you’re trying to address. This holds true in life and in programming. Effective testing requires that you have a good understanding of what you are testing and why. Without this solid foundation, at a minimum you’ll cause some confusion, and often times you’ll end up wasting time, money and energy investigating problems that aren’t really problems. This week, a company called OptoFidelity provided the perfect opportunity to discuss this challenge that engineers and testers commonly face.
Nearly a year since the last refresh of the iOS testing mind map, it seemed due for an update. The changes in this version are outlined below.
- Added iPhone 5s (64-bit)
- Added iPhone 5c
- Removed iPhone 3G
- Added LTE
- Time Settings
- Added 24 hour clock
- Time Settings
- Added 7.x
- Added Motion Activity
- Added Restrictions
- Added Disabled Safari
- Added No IAP password caching
- Added Disabled Camera
- Added Privacy
- Added Location Services, Contacts, Calendars, Reminders, Photos, Bluetooth Sharing, Microphone, Motion Activity, and Social Networking
- Added Push Notifications
iOS Testing Mind Map 1.2
A few weeks back there was an abuse of Apple’s Enterprise Developer Program that gathered a lot of attention after it was used to distribute a GameBoy emulator outside of the App Store. Obviously the focus at the time was on the fact that anybody could build an app to distribute outside of the App Store by using one company’s enterprise certificate. What got no attention, as far as I can tell, was the lack of security on the build server.
Just about every beta I’ve participated in has been set up in a way that feedback is only sent back to the developers. Vesper is my first time on a beta where a collaboration tool was set up for testers, in this case Glassboard. For those unfamiliar with Glassboard, it’s a sort of social network that allows you to create private boards for groups of people to communicate. Its lightweight structure is well-suited for private communications amongst a small group, like during a beta. Brent Simmons explained to me that this is how he has always done betas. Whether it be email, Glassboard, or some other tool, Brent has always set up a way for testers to discuss the project with one another.
Of all the instruments available on the iPhone, GPS is easily one of the most utilized. Having access to Location Services can greatly enhance user experience in your app by adapting behavior to what best suites your user based on his or her whereabouts. One critical piece to utilizing location services is making sure your code behaves the way you expect. Fortunately, in recent releases of Xcode, Apple has made this job a little bit easier by allowing us to spoof our location in the Simulator and on devices.
iOS Simulator comes with a number of debug options to assist you in testing your iPhone and iPad apps. Two of of my favorite and most used options are found near the bottom of iOS Simulator’s Hardware menu: Simulate Memory Warning and Toggle In-Call Status Bar. We haven’t yet covered the in-call status bar and it’s often and overlooked and under-tested scenario that deserves some attention.
Today Panic announced the release of their new iPad app, Status Board. I was fortunate enough to have the opportunity to spend some time with it before its release and I can confirm what most of you probably already anticipate; it’s a phenomenal app. I’ll spare you another review, because there are already great ones to be read elsewhere. But there are a couple of features in Status Board that I wanted to talk about. Ones that I think have a tremendous amount of value and potential.
Wonderful news in the HockeyApp community today. Brian Gilham and Mark Pavlidis have released their native HockeyApp client for iOS: Goalie. HockeyApp is a platform for managing your apps. It offers everything from beta management to crash reporting and has become an indispensable tool for many developers and testers in the iOS community (and elsewhere) including myself. If you haven’t checked HockeyApp out yet, you should.
Discussions have been taking place for a long time about Apple’s deprecation of UDIDs, what options developers have for replacing their use, and what it means for user privacy. Since Apple has now officially announced that developers can no longer use UDIDs as of May 1st, it seemed worth taking a closer look. What I found when looking into Advertising IDs, identifiers for vendors (IDFVs), and the “Limit Ad Tracking” feature that Apple added in iOS 6 was a lot of confusion and misinformation about how all of these things worked. To try and bring some clarity to the issue, I decided to do a detailed write-up on Double Encore’s website. The explanation is geared more toward end users, but I think even more technical folks may gain some insight from it.