Posts tagged Apple

Developer First Impressions of the 2016 MacBook Pro

I haven’t been an “Apple” person for long, but since I bought my first MacBook Pro in early 2013 I was really impressed with the quality of the hardware, the feel of the device, how small and lightweight it was was light-years ahead of any other laptop I could buy at the time. The MBP turned into my travel laptop of choice, I had 2 Windows laptops (1 from Dell the other from Asus) that I just stopped using and gave away. A .Net Developer only traveling with a Mac, that was crazy talk.

IMG_4038Fast forward, 3 freaking years without a meaningful hardware upgrade, and were now in 2016 and a new MacBook Pro has been announced. It’s a significant hardware upgrade over my 3 1/2 year old MBP, but not so much if you have a kitted out version of the last revision.

As I started to write this I’ve been using it off and on for a couple of days into my 10 day stress test, so not really stressing it yet. But I’ve already noticed a few things.


  1. Build Quality Is Amazing, as usual: When your paying top dollar for a laptop we expect it’s going to feel good. The system is solidly built, it it’s noticeably smaller and lighter then my 3 year old MBP, but has a solid heft to it. Opening and closing the screen is fluid and sturdy.
  2. Hardware Spec’s are “Meh”: I went for the upgraded processor and video card. For me when I travel I like the ability to play games. I only went with the 512GB SSD, as the 1TB model was an extra $400 bucks and I could not justify that, I’ll just carry around some 128GB Thumb Drives, not that big of a deal. But power wise the Surface Book seems to have the edge in terms of raw horse power.
  3. Ports aren’t “Portie”: Apple FINALLY went with standard ports, but unfortunately they picked ports that almost no one else uses. This means I had to replace my almost $200 bucks worth of adaptors for my old MBP. I was also a fan of the MagSafe charger, kinda sad to see that go.
  4. Screen: The new MBP’s screen is really nice, very crisp and bright, color seem good and vibrant.
  5. Trackpad: I am not a fan of the larger trackpad that takes up the entire middle of the front of the laptop. I don’t mind the loss of the mechanical press on the trackpad and instead going haptic, it still feels ok, not great. But the damn size, with my larger hands my palms routinely pour over the pad and that sometimes causes issues. Minus some ghost mouse movements, and clicks, it’s uncomfortable, there’s a lip around the pad and you can feel that on your palm.
  6. Touch Bar: Every review out there is glowing about the touch bar, but for a developer, this downright sucks. The touch bar is an OLED screen, and inset into laptop below the levels of the keys in the keyboard. When typing there is no way to correctly position your fingers to ‘feel’ if your pressing the right OLED button. To me this Touch Bar is a gimmick and a step backwards for any keyboard warriors.
  7. Keyboard: This is my biggest gripe with the new MBP. They keys are the new ‘butterfly’ design and have almost no key travel. There is a satisfying ‘click’ when typing but almost no physical feedback of a keypress. The keyboard layout changes also are not good, the arrow keys particularly are completely messed up, I guess they didn’t like the space above and below the left and right arrow key? Like serious WTF.

I’ve never before considered returning an Apple product, but after a day of use I looked up their return policies. Including taxes I spent $3,300 on the laptop and tack on another $400 for Apple Care. I still don’t know if I’m going to keep the new MBP, I’m seriously considering a Surface Book or Razor Blade as alternatives and keeping my old MBP for XCode builds.

If you’re a First Responder or know one check out Resgrid which is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations.

Mobile Development and the Support Burden

Thinking of selling a mobile application? You should be aware of the support burden of supporting an on-device mobile application. When you really think about it applications on mobile devices are the wild-wild west when it comes to their install base, hardware configuration, operating system, capabilities and current state. Android is by far the most fluid with Windows Phone 8 probably the most static.


In the last 2 years I’ve really gotten into Mobile Apps, both native at the start and now hybrid. I will save the Native verses Hybrid discussion for a latter time, but they both have positives and negatives when dealing with support for your customers.

It wasn’t until I started developing the mobile apps for Resgrid did I fully appreciate the support burden that can arise form mobile app development.

Resgrid is a cloud service company providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in 2012 by myself and Jason Jarrett (staxmanade). We have currently 2 hybrid mobile applications 1 one legacy native one that we are in the process of replacing.

In the last year I’ve also had the luxury of being part of enterprise grade mobile app development at Paylocity, which is a cloud service provider of payroll, human resources and time & attendance products and services. Both of those experiences have given me some great insight into challenges faced by companies supporting mobile applications.

So your only going to develop for iOS, seeming it’s Apple, they control everything and it’s all a known quantity. Well your first problem is that every phone is it’s own unique little snowflake, in addition that unique little snowflake varies wildly depending on where it is. For Apple, say you only do phones, and iOS 7.1+, that gives you the iPhone 5, 5S and 5C (pretty small right?). You still have a good size support burden.

Factor 1: The Hardware

Even with a hardware universe as small as the iPhone 5, 5C and 5S there are some drastic differences between the phones. Between those 3 phones there are 21 models. Check out this article from EveryMac that breaks down the hardware and usability differences between the 5,5C and 5S. So potentially in just those 3 phones you have 21 instances where you app could operate or act differently. That’s assuming a constant baseline of OS, installed apps, running apps, network, environmental conditions, accessories and user.

Although the newer phones high end phones have some good hardware spec they still can have some serious performance concerns. How many background tasks are running? Is there competition for the same resource? Mid range and cheap phones have pretty much barebones specs.

Factor 2: The Operating System

Operating System fragmentation is a huge issue. Up until iOS 7 the Apple iOS fragmentation wasn’t a big deal, but iOS 7 cannot be installed on older devices, like iPhone 3’s and older, first gen iPads’ etc. Here is a good article from December 2013 detailing the fragmentation issues on iOS and Android.

Factor 3: The Network

Can you hear me now? Ok sorry. This really is a huge issue. Most of our apps need to transmit and receive data. But how performant and error prone that process is can vary wildly depending on the network, the connection, signal strength and congestion. Just walking around my house on a cell connection I can get errors in my app sometimes, it’s not the apps fault or the backend service, it’s the network.

Factor 4: The Browser

This is more a problem that specifically affects hybrid applications, but it’s such a huge problem for mobile apps that it needs to get it’s own section. Mobile browsers pretty much suck. Some are far better then others, I think Mobile Safari is probably the best default browser. Sencha has a great article on mobile browser performance, the gist, mobile performance can suck especially on older operating systems and hardware.

I’ve found through experience that Android mobile browser is worse then iOS, especially on Android 4.2 and older. In one case I’ve seen something completely usable in an iOS 7 device and unusable on an Android 4.2 device.

Factor 5: Accessories

You design your app with swipe gestures, say to open a drawer menu, did you take into account the cases people have on their phone? An Otterbox Defender case adds a 1/4’th the depth of the phone lip before the screen, making it hard for people to swipe in from the sides.

Other accessories like screen protectors can fade out the screen or wash it out. Making text harder to read, or small details to be visible.

Factor 6: Environment

You wouldn’t think that environment can be a problem, oh but it can be. From a app details being washed out in the sun, to trying to get a GPS fix where your customers are physically using your app can impact perceived and actual performance and usability.


Based on the factors above support request and issues from even a single user can vary wildly. At Resgrid we’ve had the same user say the app’s performance is amazing over a cell connection and the next day (in the same area over the same connection) say the app is unusable. I’ve even had people that somehow got the Resgrid Responder app loaded on jail broken devices and sent scathing support emails when it wasn’t working.

There is a lot of upside to developing mobile apps, but you need to take into account all the form factors, hardware configurations, networks and usage scenarios to help prevent errors and user issues before then happen and to better support your users.

Go to Top