xcode

The Waiting Game

Patience has never been one of my strong suits. As such, it’s no surprise that as I wait for my son to make his debut into this world, I’m finding it more and more difficult to concentrate on coding. I have a good, solid to-do list set up for Corgi Corral so that I won’t forget where I left off, but basically, I’m just ready to have this baby. (Seriously, any time now would be excellent. Today would be great!)

It's been 84 years

And speaking of waiting: I’ve been waiting to buy a new MacBook Pro for what feels like a very, very long time (how’s that for a segue? lol). I originally assumed that new Skylake MBPs would be announced this month; however, most rumor sites now seem to agree that they won’t be unveiled until WWDC in June. Now I’m even hearing rumors that while the 13″ MBP will be ready for release in June, the 15″ might not be available until September. September? I really, really don’t want to wait until September.

Honestly, it’s made me re-evaluate whether or not a 15″ MacBook Pro is what I even want or need.

The Xcode Problem

One thing we’ve surely learned from the endless “Mac vs. iPad” debate is that everyone uses (and passionately defends) the tool that works best for them. On a recent episode of the Accidental Tech Podcast, the hosts briefly discussed the possibility of Apple releasing a version of Xcode for the iPad (which seems like a real possibility).

For some reason, their discussion prompted me to search Google for the “best laptop for iOS development.” There were a number of question-and-answer threads that went something like this: “Can I use an 11″ MacBook Air for iOS development?” followed by a resounding chorus of “Get a 15″ MacBook Pro. You’re going to want more screen space. Get a Mac mini and a large display. Get a Mac Pro.”

The iPad Pro has a 12.9″ display. It’s certainly possible that Apple could find a clever way to redesign Xcode’s interface for the iPad in order to make screen size less of a pain point. But what about the simulator? And instruments? Would they run side-by-side with Xcode somehow? The logistics are baffling to me. But I digress.

The point I’m trying to make is: it seems like some of the folks who imply that they could switch to the iPad full time if only it had Xcode probably aren’t currently willing to do their work on a 12″ MacBook (and not just because of the keyboard and speed).

On the other hand, I was able to find one person who loves their 12″ MacBook for development: Rob Rhyne. Back in August, Rob wrote a very interesting post about how he sets up his little MacBook to use Xcode and Photoshop. It’s a lot of hoops to jump through (lots of hiding panels and adjusting font sizes), but no more hoops than Federico Viticci has to navigate in order to get work done on his iPad. As I read Rob’s post, I got inspired. Maybe I don’t need the classic developer workhorse after all.

overview_hero_hero

Spring is in the Air

I want something just a tad bigger than the 12″ MacBook. The rumors of new MacBook Airs intrigue me—especially the possibility of a 15″ Air. Presumably, these new Airs (or whatever they’ll be called) will be released before September. Presumably they’ll also have retina displays, a decent speed boost, and good battery life. They’ll probably be fine for photo editing, code compiling, and playing a few games and they’ll be cheaper and lighter than a MacBook Pro to boot.

My philosophy has always been to buy the most powerful laptop I can afford and use it for as long as possible. But times are changing, and maybe I need to refresh my thinking as well. After all, I’m not a professional photographer, designer, videographer, or musician (though I like to dabble in all of those things). I’m not even a professional developer. If I want to run graphics-heavy games, I have a gaming PC for that. I rarely hook up peripherals to my laptop. Really, I honestly can’t think of a single reason that I would need a MacBook Pro over a refreshed MacBook Air.

And that’s…freeing. If, like me, you’ve been waiting ages for new MacBook Pros, I’d encourage you to spend some time thinking about what you really want and need. Maybe, like me, you’ll come to a different conclusion. :)

HELP! Squash a Bug, Save a Corgi [Updated]

UPDATED 3-12-16, 2:04PM CST:  I’ve actually been trying to figure out this bug for months, and, of course, as soon as I posted about it I figured it out. :D As it turns out, I made a real rookie mistake and messed up my Storyboard segues. I’m going to write a follow-up post explaining what happened…hopefully it will benefit other beginners like me!

Ok y’all, I’ve finally run into a bug that I can’t figure out, which means: the fate of Corgi Corral is in your hands. I’m posting here first, but if I don’t get a response, I’ll try Stack Overflow.

The Bug

Corgi Corral’s navigation stack is set up in a Storyboard and works like this:
Main Menu –> Scene Selection –> GameViewController –> Score Summary

From the Score Summary, the player can either retry the current scene, pick another scene, or return to the main menu.

The bug, which causes the app to slow to a stutter but not crash, occurs when I play four games in a row and then try to start a fifth. So, like this:

  1. Play Level 1 – all good, game plays at 60fps
  2. Play Level 4 – also good, game plays at 60fps
  3. Play Level 3 – things are still great, 60fps
  4. Play Level 2 – excellent performance here as well, 60fps
  5. Play Level 1 — when I return to Level 1, the segue between the Scene Selection screen and the GameViewController suddenly slows to a snail’s pace, the game’s framerate drops to 1fps, activity on all threads plummets, and the overall CPU usage drops to just about nothing. The Level1.sks file seems to load properly, everything is just slow.

The bug also occurs if I retry one of the scenes (so like: 2, 3, 1, 1, 2) instead of playing four different ones.

Since a crash never actually occurs, I paused execution right after the slowdown and took this screenshot of the debug navigator (click to enlarge):

debug navigator

However, I can’t make any sense of it. All I know is that I don’t seem to have a memory leak.

The Trace

I opened up the Time Profiler and recorded myself playing four games and then starting a fifth. I saved the trace, which you can download from Dropbox. (Note: it’s a 50MB file, since it took me about 6 minutes to reach the bug). The problem occurs right around the 5:15 timestamp.

Theories

I’m not experienced enough to be able to debug a problem like this. But I’m guess it has something to do with threading? Or texture loading? Or both? All of my scenes are loaded from .sks files. All of my sprite images are in the asset catalog (which, from what I understand, is necessary for app thinning and should behave like a texture atlas as of iOS 9). I’m not doing any on-demand resource loading. I don’t have any code related to Grand Central Dispatch. The game is accelerometer-controlled, so CPU-usage is naturally high during playtime. When I try to start that fifth game though, it’s like the accelerometer just gives up. Am I hitting some kind of system limit?

Comments are open, because I’m desperate. I’ll update this post with any additional information requested, and also if a solution is found. Thanks in advance!

Resizable Button Backgrounds in Xcode

Every once in awhile I discover a little feature in Xcode that I never noticed before and wonder how in the world I could have missed it. Today’s lightbulb ? moment is brought to you by: “image slicing in the Xcode asset catalog.”

See, I made this button in the shape of a dog treat:

bone_button_slicing1

I’ve been using it as the background for my “Play” button on Corgi Corral’s main menu screen. My concern was that when I localized the word “Play,” there might be a translation that caused the word to be too long for the button at the size I designed it. It would be better if the button background itself could scale its width without looking weird and stretched. That’s when I noticed the “Show slicing” button in the bottom-right corner of the asset catalog.

When you click “Show slicing,” your image appears larger and is overlaid with a button that says “Start slicing.” This is where the fun begins! ?

Slicing a button

You have three options: slice horizontally, vertically, or both. Slicing horizontally automatically preserves the end caps of the button while simultaneously creating a 1-pixel vertical slice that can either be tiled or stretched, depending on your preference.

Sliced button

After slicing the image, you’re done—there’s no “save changes” or “done slicing” button to press. When I switched back over to my Storyboard, however, my bone button was looking a little squished:

Squished bone button

To fix that, I adjusted the content insets on the button like so:

Left and right content insets set to 80

Ah, much better.

And that, my friends, was a quick tutorial on something you probably already knew about. Have a great day! ?

Finding My App’s Memory Leak

My plan was to write a quick post explaining how I figured out the source of my app’s memory leak; however, I’ve run into two problems: 1) I think my app actually has a few other minor leaks, so I didn’t fix it completely and 2) the “Allocations” instrument in the latest Xcode beta is absolutely refusing to work now, so I can’t recreate what I saw the other day and take screenshots. As soon as I’m done writing this, I’m going to file a radar because I was able to reproduce the crash using Apple’s own sample game, DemoBots.

Anyway, there are still a couple things I can show you. First, I ran Corgi Corral on my iPhone 6S and played the same level twice. In between levels, the app transitions to another view controller that gives a summary of your score. As you can see, the second time I played the level the app used more memory than before. Each time I hit “retry,” it increased ever so slightly.

Debug navigator

If I hit the “Profile in Instruments” button during gameplay, my app would immediately crash (which is why I’m filing a radar). However, for awhile I was able to get the “Allocations” tool to collect data on the score summary screen. Now, I can only get it to run on the main menu without crashing.

Transfer to Allocations

For what it’s worth, it doesn’t matter whether I select “transfer” or “restart” — the app still crashes, except on the main menu, where I can at least show you what the memory-analyzing tool looks like when it’s running:

Allocations and leaks

See those little green checkmarks next to “Leak Checks”? When I reached my score summary screen, those were showing up as red icons with an “x” in the middle. When I clicked the red icon, it showed me a list of objects that weren’t being deallocated. The list included many instances of “GKAgent2D,” “GKGoal,” “GKBehavior,” “GKComponentSystem”—enough instances to cover the number of sheep in the level. Evidently, even though the SKSpriteNodes were being removed from the scene (and their agents from the scene’s agent system) when the sheep entered the pen, their GameplayKit agents were refusing to die.

I’m hoping that the next beta of Xcode 7.3 will fix my profiling problem, because I’ve become really interested in learning how to analyze my game’s performance! I’m sure there are many more problems to be found and optimizations to be made. For now, I’m off to file a bug report!