I use Xcode in one of two ways. I either use it at a desk with a minimum of three displays (without using fullscreen or spaces) or I use it on a laptop with a lot of full screen spaces each in “split” mode with the .h file on the left. One thing that really bothers me about the latter is when I’m using the iOS simulators, it jerks to the non-space Desktop because the simulators aren’t full screen. This is also frustrating because my console output is back in the Xcode window.

My number 1 feature request for Xcode 5 is full screen mode for the iOS Simulator with console output available on the same screen. Yes, this would make the simulator viewport off-center. A full screen simulator could potentially lose some chrome too. Testing iPad apps on the 11″ MacBook Air is particularly difficult. Even though the air is 1366×768, big enough to fit a non-retina iPad’s 1024×768 landscape, the border of the iOS Simulator and the systemwide menubar make this impossible without scaling down the simulator.

The simulator could do a better job of being a fake iPhone. It would be great if it could show up in iTunes and Image capture so I could more easily dump image libraries on there for testing.

Currently, the simulator needs to reboot when you turn a simulated TV Out window on or off or change its size. This makes it impossible to test connection notifications. At this point, the iOS simulator needs to simulate a full AirPlay receiver (basically an AppleTV simulator with just the settings app), complete with the ability to simulate low bandwidth situations.

***

Xcode itself needs to stop changing my viewport on me and instead use better notifications for when things go wrong, like when I hit a SEGFAULT and it highlights return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); in main.m for me and I have to go back to whatever line the cursor was currently on manually, by clicking back and then re-scrolling to it because it doesn’t remember.

Another way Xcode gets in the way is that every time you build with an error or warning, the left pane reopens. Unless I have all the luxury of a 1920 logically wide display, I need to close the left pane to have room to work, especially if I’m in interface builder.

***

Development in general would be greatly improved if Apple put enough RAM in iOS devices to be a little less hasty about purging RAM. I don’t necessarily mean closing background apps, I mean when ARC releases something if I don’t use it literally the next line after creating it. The only way around this is to create a lot of globals, which uses more RAM because I’m not allowed to release them manually. Don’t get me wrong, ARC is the way of the future and obviates that nonsense we used to call garbage collection, but it’s not perfect yet.

Storyboards are great. Keep them optional.

Auto Layout is not. Please don’t kill springs and struts.

The documentation of appearance and its autocomplete / what counts as a syntax error needs a lot of work. The crashing [[UISwitch appearance] setTrackTintColor:green]; doesn’t even send up a warning. (UISwitch cannot setTrackTintColor, that’s for UIProgressviews, and not for UISliders either. UISwith has setTintColor and setOnTintColor). This, btw, is one of those errors that highlights main.m because it has no idea wtf just happened.

Unless using the Navigation bar and toolbar that are built into a UINavigation Controller, the ones you create manually don’t auto shrink in height on iPhones in landscape, and the way to do it in code is weird and messy. A checkbox in interface builder (accessible by code too, of course) is necessary.

***

Back to the Mac

UIKit is so far ahead of OS X. UIImageView, a class I use in literally every app, doesn’t have an equivalent on OS X. By equivalent, I mean an image viewer with the ability to set scale its contents to fit, fill, stretch, or 1:1. If I want to do that in OS X I have to start writing code in drawRect methods.

UIKit widgets also have a lot more events to take advantage of touch as thumb down, touch up, , drags, enters and exits, and value changed. These make iOS programming more similar to the ease of .net and Basic OS X falls far short of.

UIKit could benefit from vertical and circular sliders though, even if the circular slider does have a large minimum size.

The code-heavy way both iOS and OS X handle radio buttons and select-one elements is annoying.

***

Probably the two biggest requests for iOS are the opening of development for share sheets and the notifications area. I would immediately write a display brightness thing for the notification area and a “fix with Auto Adjust” share sheet.