Sandmoose

Proxying network traffic through Charles is a common practice with iOS developers which helps us examine our application's API requests and responses. Since tvOS doesn't have a UI for setting an HTTP proxy, how is this done with an Apple TV? Answer: Custom Profile.

First download Apple Configurator 2 from the Mac App Store. This is how you'll add/remove profiles for your Apple TV.

Open Apple Configurator 2 and select File | New Profile (⌘N).

In the Global HTTP Proxy section add the IP address you want to proxy through.

Save the profile. It should have a .mobileconfig extension.

From the main Configurator screen, assuming you have your Apple TV connected via USB, right click on your Apple TV and select Add | Profiles... from the context menu. Select the .mobileconfig file you created in the previous step and click Add.

It should take a few moments to copy the profile to your device. Now run your app, approve the connection from Charles if needed, and watch the network traffic flow through Charles.

Except for SSL traffic. Here's how to get SSL proxying working too. This assumes you already have a Charles root certificate on your workstation. If not, see SSL Certificates on the Charles Proxy website.

Open Keychain Access, find your Charles Proxy Custom Root Certificate and make sure it's selected. Choose File | Export Items... and save the .cer file somewhere.

Switch back to Apple Configurator 2 and open the profile you had created previously. In the Certificates section click the Configure button and select the .cer file you exported in the previous step. Save the profile.

Here's a simple cheat sheet for regular people whose lives don't revolve around Brew, but want to use Brew every once in a while to install and update software.

Install Xcode Command Line Tools

xcode-select --install

Find out what's wrong with your installation

brew doctor

Update brew. Should be run once every 24 hours

brew update

Upgrade all packages

brew upgrade

List all packages

brew list [--versions]

List all outdated packages

brew outdated

Upgrade specific package

We're all aware that global variables are bad and that we shouldn't do globals. Mmmkay? But! ...sometimes you need globally available information like user interface idiom or OS version. This information is available from UIDevice and you can grab it from anywhere in your app.

Testing Device Idiom and OS Version in Swift

if UIDevice.currentDevice().userInterfaceIdiom == UIUserInterfaceIdiom.Phone { ... } if UIDevice.currentDevice().systemVersion.compare("8.0", options: NSStringCompareOptions.NumericSearch) != NSComparisonResult.OrderedAscending { ... }

However, that's a lot type type and isn't easy to read either. In Objective-C we could use macros in the pre-compiled header to make application code easier to read and write.

ProjectName-Prefix.pch

#define isPhone ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone) #define isIOS8 ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0)

Application Objective-C Code

if isPhone { ... } if isIOS8 { ... }

But Swift doesn't have macros. Swift does, however, have a global namespace. Anything in that global namespace can be access by any other file in the same module. So you can do something like this.

Globals.swift

let isPhone = UIDevice.currentDevice().userInterfaceIdiom == UIUserInterfaceIdiom.Phone let isIOS8 = UIDevice.currentDevice().systemVersion.compare("8.0", options: NSStringCompareOptions.NumericSearch) != NSComparisonResult.OrderedAscending

Application Swift Code

if isPhone { ... } if isIOS8 { ... }

Problem: You want a view controller to always display in landscape orientation. Left or right doesn't matter. Ideally, the user should be able to flip their device around to either side. As long as things are always in landscape all is good. Chances are you're looking for the UIInterfaceOrientationMask enum and not the more limited UIInterfaceOrientation.

Instantiating NSDateFormatter objects is slow. Most well-written apps that use NSDateFormatter will make efforts to reduce the number unique instances created. Using a static property is sufficient for most cases, but what if you work on a large app where lots of NSDateFormatter objects are needed by a large number of classes. Wouldn't it be nice if there was an NSCachedDateFormatter that keeps track of what it has instantiated and will return cached objects and only instantiate new ones when necessary? Wouldn't it be nice if NSCachedDateFormatter was a singleton and could be used app-wide? I wrote this class as an attempt to fulfill this need.

class CachedDateFormatter { static let sharedInstance = CachedDateFormatter() var cachedDateFormatters = [String: NSDateFormatter]() func formatterWith(#format: String, timeZone: NSTimeZone = NSTimeZone.localTimeZone(), locale: NSLocale = NSLocale(localeIdentifier: "en_US")) -> NSDateFormatter { let key = "\(format.hashValue)\(timeZone.hashValue)\(locale.hashValue)" if let cachedDateFormatter = cachedDateFormatters[key] { return cachedDateFormatter } else { let newDateFormatter = NSDateFormatter() newDateFormatter.dateFormat = format newDateFormatter.timeZone = timeZone newDateFormatter.locale = locale cachedDateFormatters[key] = newDateFormatter return newDateFormatter } } }

Use the CachedDateFormatter singleton to instantiate any NSDateFormatter object you need. The formatterWith function returns a NSDateFormatter object and stores it in a dictionary based on format string, time zone and locale for future use. If another part of the app needs a date formatter with those same values it'll get the cached version.

Usage from Swift

let dateFormatter = CachedDateFormatter.sharedInstance.formatterWith(format: "yyyy-MM-dd'-'HHmm", timeZone: NSTimeZone.localTimeZone(), locale: NSLocale(localeIdentifier: "en_US"))

Since Swift allows for default argument values you can omit the second and/or third argument. A minimum call that defaults to the local time zone and "en-US" locale would look like...

let dateFormatter = CachedDateFormatter.sharedInstance.formatterWith(format: "yyyy-MM-dd'-'HHmm")

Usage from Objective-C

Objective-C doesn't support the concept of optional arguments so it must always be called with all three arguments in Objective-C.

NSDateFormatter *dateFormatter = [[CachedDateFormatter sharedInstance] formatterWithFormat:@"yyyy-MM-dd'-'HHmm" timeZone:[NSTimeZone defaultTimeZone] locale:[NSLocale localeWithLocaleIdentifier:@"en-US"]];

Sometimes it's nice to be able to insert an image into a UILabel. Initially, I was prepared to deal with container views, subviews, and autolayout, but it turns out to be much easier than that in iOS 7+ with NSTextAttachment.

If you're using the default flow layout for your collection view and have defined the cell size in Interface Builder, here's how you can retrieve the cell size programmatically. This assumes a UICollectionView outlet property called collectionView.

UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout*)self.collectionView.collectionViewLayout; layout.itemSize

For the past few weeks I've been trying to decide which Apple Watch I'm going to order on midnight April 10th. Obviously, it'll be one of the Sport models. The stainless steel models are too pricey for a first generation product. Maybe after the third or fourth revision when it's much better than the current models I might be willing to spend the extra money for a stainless steel model. However, for now I just need to decide which color of Sport model I want.

The initial candidates were white, blue, and black. I ruled out white early on due to concerns about discoloration after wearing it for a long period of time. In choosing between blue and black I initially leaned towards blue. As I get older I prefer "lightness" in my life. The silver aluminum and light blue band is certainly lighter, and more cheery and fun looking than the all black model.

I also appreciate that the silver aluminum case is honest about what it is. It looks exactly like the material its made out of and nothing more. The black aluminum model seems to be covering up its true roots. Like it's trying to be something fancier than what it really is. For a while I had my mind set on blue. If I was only going to wear the Apple Watch inside my own house then I'd be completely comfortable with that choice.

The new MacBook is an amazing feat of engineering and a beautiful machine. I find it interesting not because I want one for myself though. I'm a professional and actually need more speed, more memory, more storage, more screen, and more ports. The MacBook Pro is the machine for me. There's a reason why they put "Pro" in the name. Instead, the new MacBook is interesting because we know elements of it will find their way into future versions of the MacBook Pro.

The Force Touch trackpad is already in the 13" MacBook Pro. It's seems a given it'll eventually make it to the 15" as well. The new keyboard will probably make its way to the MacBook Pro as well. I'm also curious to see if the different color options will be available as well or if that will remain strictly a consumer MacBook thing. If gold and black make it to the MacBook Pro will the iMac eventually get those colors too?

I recently got my first Retina MacBook Pro when I started my new job last November. It is an amazing screen and I planned to use it as my primary display from that point forward. Never again, would my eyes look at a chunky non-Retina screen again.

However, a 15" inch screen isn't very large and Xcode really wants a lot of space. Especially if you're working with iPad storyboards. Nevertheless, I stuck with my Retina-first policy in an effort to reset my default expectations to fit a 15" screen.

Yesterday, just for kicks, I decided to hook up my 27" external monitor as a primary display and position the Retina MacBook Pro off to the side. I've discovered that I really do value the extra space over the sharpness of the Retina display.

It feels so much more "freeing" to have lots of space to arrange windows in. It feels great to let Xcode stretch itself out as big as it needs to be. On the 15" screen I find myself actively hiding/showing Xcode's various panes (Navigator, Editor, Inspector, Console) to optimize screen space for whatever task I happen to be doing at the time. With the 27" screen I can let all the panes be visible all the time with no ill effect. I'm not distracted with hiding/showing stuff and can focus on what I'm doing instead of window management.

I’m dealing with the very real first-world problem of deciding which bigger iPhone I want.

The case for the 5.5”

Optical Image Stabilization — Apple says it’s supposed to help in low-light conditions which would be almost all of my photographs. Can I be satisfied knowing I didn’t go for the absolute best camera available especially when I would supposedly benefit from it quite a bit?

Bigger and easier to read text for my aging eyes. I can bump up my default Dynamic Text size and still have lots of room for the bigger text.

It might be a reasonable size for reading eBooks for extended periods of time. Also, a 6 ounce iPhone 6 is a heck of a lot lighter than a 1 pound iPad Air. A big benefit when reading in bed.

Better battery life than the 4.7”. But I don’t know if it’s going to enough to break the 1-day barrier which isn’t a problem for me now anyway. The first iPhone that I only need to charge every other night is probably still a ways off.

401 PPI display! I probably won’t be able to tell a difference though. I already can’t discern pixels at 326 PPI which the 4.7” has. (See aging eyes from above.)

That landscape stuff in iOS 8 looks kind of cool. It might make dealing with email on the iPhone more pleasant.

Sharing cool movie trailers, funny cat videos or Weird Al music videos with the kids means a bigger screen to huddle around. I know there’s Air Play but many times it’s much easier to say, “Hey kids! Come check this out!” with zero fussing.

Games. Despite having an iPad I do most of my gaming on my iPhone because it’s the one device I always have with me. Monument Valley would look pretty cool on a 5.5” screen.

I’m not an old person. Not mentally anyway. Young people boldly move forward and eagerly try new things. If I’m going to be getting a bigger phone anyway then why not get the one that’s really bigger instead of one that’s just a little bit bigger. I can always get a smaller one in two years if I really don’t like the 5.5” size.

The case against the 5.5”

It’s much bigger. It might be unwieldy. The Reachability feature looks like it handles the vertical stretching problem but stretching my thumb horizontally across the bottom of the 5.5” screen is going to be nearly impossible. How often do I do this though?

Heavier. But the 4.7” is heavier than the current iPhones too. The 5.5” is just more heavier.

I might look like a tool using a giant iPhone in public. We all like to think we’re independent mavericks who don’t care what other people think but it does matter how you look and how other people perceive you. We all care about what kind of image we’re projecting to other people. It just a matter of how far down that path you go and how much you depend on the approval of others for your own happiness. There’s a difference between curating your outward image and being dependent on the approval of others for your happiness. Anyway, there are enough big Android phones in the wild that I think it’s already socially acceptable. I almost never hold my iPhone up to my face anyway.