Verifying assets with the iTunes Store… solved

Verifying

Your mileage may vary with this post, but in my case, I was chasing my tail for some time while finally coming to a solution.

At work, I generally author all kinds of prototypes. Sometimes I use Xcode and author iOS applications with interesting levels of interaction and communication. In these cases, I often need to share my work with a designer who lives several time zones away from me. Instead of him installing Xcode and building to his own devices while utilizing source control, I can swing a binary his way using TestFlight. This works pretty well. Until recently.

I would archive my project and attempt to upload it to App Store Connect so I could assign it to the designer and they would be able to install directly from TestFlight on their device.

This time the upload stuck at “Verifying assets with the iTunes Store…”

Googling for answers, I came across a lot of chatter about getting off a corporate network because of potential port blockage that would allow the upload to complete. That did not work for me. I tethered to my iPhone X, public Wi-Fi outside my work LAN, etc. Those did not work. My upload remained stalled at the same place each and every time. I restarted my laptop. No difference.

I then did the following which actually told me what was going on:

  1. Create an Archive in Xcode of my project.
  2. Export the archive to my desktop instead of uploading to the iTunes Store. Saved to my desktop.
  3. From Xcode, I launched the Application Loader. Selected the .ipa generated in step 2 above.
  4. After getting stuck during the same activity, AL actually gave me a bunch of error feedback. I forgot to apply artwork for all of my application’s icons. Oops. Without using AL, I never would have known this.
  5. I assigned all the icon images in the project – then tried to upload a new archive from Xcode.
  6. It was stuck yet again. No idea why.
  7. I took that new archive, exported again to my desktop. Used AL to upload the newly created .ipa to the iTunes Store.
  8. This worked quickly and just fine!

I had become so used to authoring my own prototypes (apps) without worrying about icons for TestFlight that I simply didn’t include them. I spent a few hours trying to solve the problem. It seems there is still some sort of thing preventing me from uploading an archive directly through Xcode – I still needed to use Application Loader. However, I was able to get the binary uploaded, and after about 10 minutes it was processed and ready for TestFlight activity.

Monitoring the closest 20 regions – how?

iOS allows each application to monitor up to 20 regions. That seems like a lot, especially when you figure that the regions are registered and can be triggered (entry and exit) even while your app is backgrounded or your phone is on standby. So what do you do when you have more than 20? iOS will simply ignore them if added to your locationManager.

You can monitor the 20 closest (most likely) to be encountered. Why bother registering for regions that are far away? So in theory upon significant user location change, triggering a region, etc.

  • stop monitoring for all regions that may exist for your location manager
  • find the 20 closest regions from the user’s location
  • register for those 20

Rinse and repeat based on your own logic (as mentioned before as significant user location update, the addition or subtraction of a region, etc.)

For me personally, I wanted to figure out how to do this myself. I know I needed to perform a sort based on distances.

I had an array of CLCircleRegions.

var monitoredRegions:[CLCircularRegion] = []

I pushed into that when placing my pin annotations on the map. You can’t sort them though. Hmm. I needed something with a property I could sort. So I created a struct with a region and distance.

struct SortableRegion {
    var distance: Double
    var region: CLCircularRegion
}

Cool. Getting closer. We can sort on that distance property. Here is a function that basically does what I need it to do. I’ll walk through it after showing it to you.

func checkAndMonitorTwentyClosestRegions()
{
    stopMonitoringAllRegions()
        
    if monitoredRegions.count > 20
    {
        print("we need to only monitor the 20 closest regions. Call this anytime regions are added, removed, or the user moves significantly.")
            
        var sortableRegions:[SortableRegion] = []            
        let location: CLLocation = CLLocation(latitude: myMapView.userLocation.coordinate.latitude, longitude: myMapView.userLocation.coordinate.longitude)
                
        for region in self.monitoredRegions
        {
            let fenceLocation = CLLocation(latitude: region.center.latitude, longitude: region.center.longitude)
            let distance = location.distance(from: fenceLocation)
                    
            let sortRegion = SortableRegion(distance: distance, region: region)
            sortableRegions.append(sortRegion)
        }
                
        let sortedArray = sortableRegions.sorted {
            $0.distance < $1.distance
        }
                
        // Grab the first 20 closest and monitor those.
                
        let firstTwentyRegions = sortedArray[0..<20]
        for item in firstTwentyRegions {
            let region = item.region
                locationManager.startMonitoring(for: region)
            }
        }        
    } else {
        print("Less than 20 regions, monitor them all.")
        for region in monitoredRegions {
            locationManager.startMonitoring(for: region)
        }
    }
}

Right off the bat, I call a method that stops monitoring for all regions a location manager might have. Basically just:

for monitored in locationManager.monitoredRegions {
    locationManager.stopMonitoring(for: monitored)
}

Now I check how many regions there are. If there are less than 20, we register them all. Easy. If there are more than 20, we need to find the nearest 20 of them and start monitoring those.

I created an empty array typed to SortableRegion (that struct I made). I then grabbed a reference to the user’s location. We want to use that to determine the distance to the center of every region. I create an instance of SortableRegion and append that to the array. For each region. So each instance now has reference to the CLCircleRegion as well as the distance. Perfect. We then sort the whole thing when we’re done based on distance, lowest to highest.

Then we make an instance of the sorted array (using a range) – grabbing just the first 20 items. Pretty nifty. We loop through that array and using the reference to CLCircleRegion, monitor for each one. When you want to check again, make sure the monitoredRegions is properly updated first, and then call the checkAndMonitorTwentyClosestRegions function and you should be all set.

WWDC 17 Packing List

WWDC17

It’s almost time for WWDC17, this year in San Jose, CA instead of San Francisco. I haven’t been in several years because my lottery skills are obviously lacking. I managed to score one this year and I’m pretty excited. What will I take this year?

Well, to be honest, taking a laptop to sessions in the past, for me, has been serious overkill. I might jot some notes down in a Moleskine or other notebook – for transcription later. Taking notes on a laptop brings distraction to the game for me. Am I plugged in and charging? I need to get close to a plug. Oh, I can check Facebook during this session. Email. Pretend to be coding something amazing in Xcode. Taking notes on a laptop makes me feel like a court stenographer and I want to relax a bit and take the information in. I can always watch the session again later in its stored video format (to catch some details that might have gone by too quickly).

I will still take my trusty MacBook Pro R, but that will be for when I’m back in my room at night – coding, emailing, sorting photos, watching session videos again, etc. It will probably stay in my room locked up. Charged and ready for my welcome return at the close of each day. That will save me a bunch of weight to lug around too. I can use my laptop bag for other things, including hoofing multiple Odwalla juices around (if they supply those big cans of it around the venue).

For travel:

  • Bose QuietControl 30
  • Bose QuietComfort 35
  • Casio ProTrek PRW 3100y-1B (all black) watch

For the sessions:

  • iPhone 6 Plus. The most important bit of gear I have.
  • At least two portable battery chargers. Anker Astro Pro Series(20000mAH) and a RavPower (16750mAH)one I had before the Anker. Both charged up and ready to fly. The Anker needs plugged into an outlet, the RavPower does microUSB for charging.
  • Two point-and-shoot cameras – both Sony. An older one which is my favorite, and a newer model which I don’t like as much.
  • Timbuk2 messenger laptop bag.
  • Moleskine, fountain pen, EDC pens, etc.
  • Zojirushi Coffee Thermos 20oz. Über awesome and über important.
  • Various cables, USB wall plugs, etc.
  • Takeya ThermoFlask Insulated Stainless Steel Water Bottle, 40 oz, Asphalt. Huge. Perfect. Might leave at the hotel as it could be overkill.
  • Apple Watch series 2. I’m hoping Apple updates the WWDC iOS app and it gets watch support – for keeping us on our selected schedules, getting important updates, map support, etc.
  • Sunglasses. For me, very important.

Hotel:

  • Takeya ThermoFlask Insulated Stainless Steel Water Bottle, 40 oz, Asphalt. Huge. Perfect. No water bottles.
  • Couple of polos/shirts (a few older WWDC ones, a Swift logo one, etc.)
  • Shorts/jeans/Scarpa shoes. Scarpa Margherita rock.
  • A spring jacket in case it gets cool at night (Patagonia fold up for laptop bag) – not wearing a WWDC17 one if Apple swags those out.
  • Livionex tooth gel. Its amazing.
  • Wet shaving and beard gear. Very important to clean up daily.
  • Packing cubes. Although I’m not bringing a ton of clothes, they really, really, really help keep things tidy. I know I’ll be bringing back a few additional shirts and a sweatshirt at least.
  • Snooz white noise generator (I got from Kickstarter)
Tagged : / / /

Creating a tvOS parallax UIButton

Image Stack

If you’ve been involved in tvOS application development, or you’re new to the whole process, you might find this post interesting in regards to user interface.

I have recently been involved in tvOS dabbling. I’ve been creating a custom application (no TVML) and I wanted one of those nifty parallax-style buttons that Apple uses in its media browsing (notably the TV application). You can focus an item and it will shift neatly as you move around on the Siri remote control. Perfect if you don’t need to include explanatory text. However creating one eluded me for a short while. There may be a better way to handle this, but I present to you my working solution.

TV Stack

Create an Apple TV Image Stack

You need to create a new Apple TV Image Stack in Xcode (when you have your Assets.xcassets folder selected).

The stack takes 3 files by default. I used a background white PNG, a shadow PNG, and a product PNG. If you don’t supply a solid background image, you’ll see the shadow behind your UIButton – which doesn’t look good. Drag in your images into each layer (Front, Middle, Back). You’ll get a nice preview of the parallax at the top so you can see how your images work together. This allows for you to determine if you need to make changes to get the look that you want. I’ve shown each image at the top of this post, each box representing one of them. I named mine “qc35Stack” – which you’ll need to refer to later as an image name.

stacks

Create your custom UIButton with parallax

Now that you have your image stack, you can use it to supply images for a UIButton’s various states. When you supply a stack in this way, the button will know that it should perform a parallax presentation. I created the 3 images at the same size that I want the buttons to be (i.e. the image sizes match the UIButton’s declared frame).

Here is the code I settled on.

let buttonUnpressedTexture = UIImage(named: "qc35Stack")
let buttonPressedTexture = UIImage(named: "qc35Stack")
let newButton = UIButton(type: .custom)
newButton.frame = CGRect(x: 800, y: 200, width: 180, height: 180)
newButton.setImage(buttonUnpressedTexture, for: UIControlState.normal)
newButton.setImage(buttonPressedTexture, for: UIControlState.highlighted)
newButton.setImage(UIImage(named: "qc35Stack"), for: UIControlState.focused)
newButton.imageView?.clipsToBounds = false
newButton.imageView?.adjustsImageWhenAncestorFocused = true
newButton.adjustsImageWhenHighlighted = true

Tada

Finished.

A note: I first attempted to use static PNG images for the highlighted and normal states of the UIButton, but the transitions between them and the focused were glitchy and didn’t look good. When I used the same stack for each of those states, things look good. I don’t know if this is the correct way to do it or not, but it is working.

Go ahead and try it out for yourself. It seems to work a treat, and you didn’t need to subclass a UIButton in your own Class to get it working either.

A short post because the solution is pretty simple.

watchOS: Adding a complication to an existing project?

Apple Watch Complications

Much of Xcode is wonderful to use in my opinion. You can dig and dig and dig and still find new things in there. However, there are aspects that induce sphincter tightening just thinking about it (without version control). Anything you do to a project file is scary stuff.

Recently I had a project that I attempted to add a watchOS complication to. You can’t undo that. I ended up with a bunch of extra targets, including a new watch extension itself. I wasn’t sure what I was doing and things started producing warnings and errors. I deleted a bunch of stuff  and cleaned the build folder. Whew.

Turns out, it’s quite easy to create a new project with complications present before anything. Most of the project’s code was able to be ported quite easily. Some other things took some time (plist files, user interfaces, etc.)

I have yet to find out how to add a complication to an existing watchOS application. I spent too much time searching the internet for answers. I was actually able to mostly figure out complication templates too – after a lot of trial and error. So much so that I had to use the simulator because I was building so much to get it working.

Tagged : /

keep it simple. Frameworks?

keep it simple

Recently I had a project in a workspace to produce a framework of Objective-C and Swift code – supplied by someone else. I had a devil of a time getting it to build for me. And when I did, I tried to copy it into my own project to use it – to find out somehow the project thought I already had it. So I had to link to it. Which meant building an archive didn’t work, so I added a path for embedded frameworks, and then found out there was a problem with how the framework was built in the first place. I was jumping through hoops. I’m no Xcode guru. It’s great until it doesn’t do what you want.

I spent hours trying to get things to work. Hours. The dry-heaving Xcode project red sweats. The kind you want to roll a d20 saving throw to see if it will make it to the end of the day and live on.

I took the framework project code, copied it to my swift project. Added a bridging header for an Objective-C header, and I was done. In the span of about (really) 10 minutes I could have saved myself hours. Now… if that framework changes I need to stay on top of that. If I used a linked framework under source control, I’d be better. But that framework won’t really change much at all.

Sometimes it really is better to keep it simple.

The horror of Xcode project errors.

The horror.

We have all been there, right? You design the UI, you’ve planned out the architecture and how your application will work. Days go by and you’ve got things nailed down tight. Interactions are smooth, data is flowing like warm nectar from some newly discovered fountain of awesomeness. Your project is ready for the next thing.

You build a framework and add it to your baby. Errors. Huh? Fucking errors.

You start to try different things to get rid of the errors. The errors morph into different errors. You start to edit bits of your project and you’re worried that too much is changing to accommodate this new chunk of code. Sweat on your furrowed brow as you JUST WANT TO BUILD the project again. You’re missing the ability to see your application behave and do what you want. Right now its laughing at you.

When will this stop?!

You roll back and try again. You alleviate certain errors through intuition, luck, and StackOverflow searches. You feel it slipping away from you again, you’re editing stuff all over the place. You’re getting frustrated. Oh, doh! I need to build the framework for generic iOS devices. Oh, you need to add a few keys to your info.plist. You can’t copy the file into the project because Xcode thinks it’s already referenced – so you make a copy of the framework and move it in. Gradually it all starts to come back together. You add stuff to the AppDelegate and the compiler is complaining. You get it link up and work. After hours of pounding agitation.

Of course, we’ve all been there. From 100 miles per hour to 2 miles per hour in a matter of milliseconds. You prayed. You researched. You tried little things to see if they make a difference, even though you knew they wouldn’t. You start to forget all of the things you’ve done to alter your project in the hopes of getting it to build again. You burn through hours. If it was late, you have dreams about what you might try next.

Magic. Thank you!

Some little blip from the darkest recesses of your mind floats up and sparks a solution. Or a path to one. And you walk it with your keyboard in the hopes of lighting the candle in the dank and dark room of despair.

And then it comes together. Somehow it just does. At the tail end of the journey it all seems so obvious and clear. You feel satisfaction in knowing you’re not totally screwed anymore.

That time was well spent in learning how part A goes into part B which depends on part C, D, and E. You shake your head and feel elation when your build completes without error (and any warnings are actually welcomed at that point… yellow is better than red).

Coffee tastes better. You go though and delete all those blocks of random code you ended up commenting out in favor of other mystical trial and error code.

You look at your screen and mutter the words.

“Yeah, well. The Dude abides.”

Swift 3 appearance extensions

Appearance
I just read about this and smacked myself on the forehead. Normally when developing an application I follow some sort of branding guidelines or perhaps make use of a custom font. I think most developer/designers DOI this quite regularly.

Now, I’ve found myself coding to those conventions over and over for various labels and like user interface controls. It’s a pain in the ass. If it needs to change you can search and replace in the project, or use messier methods. Not fun and prone to errors.

Extensions. We all use them too. However, they can be used to simplify your code and maintain consistency application-wide. You can put these in a separate Swift file to make them easier to track down.

/** Appearance .swift */ 
import UIKit 
extension UIColor { 
    // Custom colours go here 
    func custom() -> UIColor { 
        return UIColor(red: 0.45, green: 0, blue: 0.95, alpha: 1) 
    } 
} 
extension UIFont { 
    // Custom fonts go here 
    func custom(size:CGFloat) -> UIFont { 
        return UIFont(name: "Avenir Next", size: size)! 
    }
}

I’ll reformat the above code soon, I’m on my phone at the moment. But look at that. It can be so simple to make edits to affect a great number of controls.

Here is an example implementation of the extension.

// Use the extensions from Appearance .swift 
label.textColor = UIColor().custom() 
label.font = UIFont().custom(size: 20)

How about using static variables? Excellent and clean!

import UIKit 
extension UIColor { 
    // Static, computed variable for custom colour 
    static var custom:UIColor { 
        return UIColor(red: 0.45, green: 0, blue: 0.95, alpha: 1) 
    }
}

Now here is the implementation using a static variable.

label.textColor = .custom

Shazam. To me, this is really excellent. Easy to use, easy to modify, and it keeps your view controllers and the like slimmer and thus easier to read. No long lists of label modifications. You can take this concept quite far if you’d like to.

Protocol/delegates in Swift 3.0

I declare this day a fine day having discovered non-Objective-C protocols! No more @objc protocol usage. Now it’s as simple as something like this:

protocol myDelegate {
    func report(info:String)
}

class MyClass: NSObject {
    var delegate:myDelegate?
    var serviceType = "hephaestus"

    init(withServiceType: String){
        self.serviceType = withServiceType
        DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
            self.delegate?.report(info: UIDevice.current.name)
        }
    }

    convenience override init() {
        self.init(withServiceType: "hephaestus")
    }
}

And then in implementation

import UIKit

class ViewController: UIViewController, myDelegate {
    
    // Delegate method
    func report(info: String) {
        print("delegate: \(info)")
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        let mc = MyClass()
        mc.delegate = self
        // Do any additional setup after loading the view, typically from a nib.
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }
}

This is a really simple example, but it works and seems cleaner to me in Swift.

Tagged :

Shaking a macOS Window

There may come a time when you’d like to shake a macOS application’s window (or one of them) to reinforce an event. In my case, I am creating a macOS application that serves as a conduit to control aspects of a user experience. It communicates with an iOS application which serves as a kind of remote control for the macOS application. And settings are synchronized back and forth. It’s pretty cherry.

macOS Sierra and iOS 10 using Swift 3 are quite similar. I know enough about iOS development to make myself a drunken lumberjack in a glade of birch trees – swinging wildly hoping to hit things. Anyway, I am using MultipeerConnectivity framework for the communication discovery and data transfer (at a top-level explanation). When a connection is made (the iOS app advertises), I turn a little grey dot into a green one to show this state. When a disconnection is made, I turn it back to grey.

However, this might not be enough. I could play a disconnection tone (and I still might), but I wanted to shake the window to let someone know, “Hey! I lost a connection.” This sets expectations and it’s a cool effect I wanted to try out.

I have an extension that will do this, written for Swift 3. It’s implementation is a little different than for previous versions of Swift. Here is the extension. The Cocoa import is because I keep separate extension swift files instead of in-lining everything into a view controller, etc. This keeps things cleaner and a little easier for me and others to find.

import Cocoa

/**
 
 window?.shakeWindow()
 view.window?.shakeWindow()
 NSApp.windows.first?.shakeWindow()
 
 */

extension NSWindow {
    func shakeWindow(){
        let numberOfShakes          = 3
        let durationOfShake         = 0.3
        let vigourOfShake : CGFloat = 0.04
        let frame : CGRect = self.frame
        let shakeAnimation :CAKeyframeAnimation  = CAKeyframeAnimation()
        
        let shakePath = CGMutablePath()
        shakePath.move( to: CGPoint(x:NSMinX(frame), y:NSMinY(frame)))
        
        for _ in 0...numberOfShakes-1 {
            shakePath.addLine(to: CGPoint(x:NSMinX(frame) - frame.size.width * vigourOfShake, y:NSMinY(frame)))
            shakePath.addLine(to: CGPoint(x:NSMinX(frame) + frame.size.width * vigourOfShake, y:NSMinY(frame)))
        }
        
        shakePath.closeSubpath()
        shakeAnimation.path = shakePath
        shakeAnimation.duration = durationOfShake
        
        self.animations = ["frameOrigin":shakeAnimation]
        self.animator().setFrameOrigin(self.frame.origin)
    }
}

I certainly hope that you enjoy it.

WatchOS 2.2.2 Debug Symbols A.W.O.L.

awdebug

On Jul 18th Apple released several operating system updates. WatchOS 2.2.2 was one of those released updates. Four days ago.

Since installation I have been unable to debug watch extensions on my real device since Xcode looks for, attempts to install, and fails to install WatchOS 2.2.2 debugging symbols.

I have filed Radar # 27470205. Other developers have as well. Here is a thread about the situation on Apple’s developer forum (under Xcode/iOS Simulators and Devices). Here is a StackOverflow question about the situation.

So far there are no answers or solutions for this situation. I don’t know what is going on at Apple, but it would be nice if one person spent a few minutes and posted the DMG up so Xcode could consume and apply the debugging symbols. I know they are jamming on the Fall releases, but there has to be a DMG somewhere for the symbols right?

Relegated to debug in the Simulators.

Multi-platform API for Google Nearby Messages

I happened upon a video presentation from Google I/O 2016 that I felt was interesting. It was called “Introducing Nearby: Physical proximity within and without apps – Google I/O 2016”. I present it here for your viewing convenience.

At the 9:27 mark a feature is described as “Earshot”. This means that for devices to discover one another, they need to be within 3-5 feet of one another. Obviously this uses an ultrasonic modem. I was quite interested in this feature. BLE and BT can bleed through walls, and I wanted discovery to be limited to a room and by near field.

So I started developing for iOS using cocoapods. It’s fairly straight forwards as I went through some tutorial code supplied by Google at their Messages API center. Nearby Connections and Nearby Notifications are Android-only silos.

I began to see differences in the APIs for Android and for iOS in regards to the Messages API. What is seen in the recent I/O video above, a setDistanceType(DISTANCE_TYPE_EARSHOT) does not exist for iOS. There is a lack of parity there. For iOS, one needs to create a GNSStrategy object with GNSStrategyParams with a discoveryMediums of Audio. These equate to the same thing. But you might not know that and beat the trees for parity you won’t find.

Okay, so the APIs and documentation for iOS needs updating since Earshot was mentioned explicitly for Android in the presentation.

The iOS APIs have many deprecations – which is fine. But the documentation supplied doesn’t offer snippets or method signatures for what new methods replace them. Really? I have to StackOverflow questions for answers? Thankfully those in the know watch the Nearby tagged questions religiously – for I got answers within hours.

Please assign some people to update the documentation and perhaps rail out a Swift version. I don’t mind bridging headers, but those are probably going away in the near future.

Swift optional variable assignment with ??

Old way:

let foo = "Hello"
var bar = String? //nil
var result = (bar != nil) ? bar! : foo
print("\(result)") //Hello

Pretty nifty. I saw this online someplace. The ?? is called a nil coalescing operator. It’s used to provide a default value when unwrapping an optional type.

let foo = "Hello"
var bar = String? //nil
var result = bar ?? foo 
print("\(result)") //Hello

 

Coding the extra mile

I recently came across some labels in a design I’ve been working on that I originally deployed using NSLineBreakMode.ByTruncatingTail. Conscious of a possible situation where text coming into the system might not properly fit. It works. But guess what? After looking at some truncated text in my application I felt like other users probably will… ripped off.

Continue reading “Coding the extra mile”

Extension management for Swift projects

The way that extensions are handled in Swift is lovely. If they exist in any file, they are available project-wide. Meaning you don’t need to import them into a Swift file for functional inclusion. This is great! But if you’re working on a medium to large Swift project, you may need to tweak or add functionality to an extension or two over time.

Find In Project and other avenues of searching are available within the Xcode IDE. That introduces some cognitive load and possibly causing you to lose a thought while you’re doing some menial tasks finding code.

A solution.

You can make an Extensions.swift file in your project and keep all your extensions in it. Import what you need at the top of it – usually UIKit should suffice. You could use //MARK: – UIView – type browse tags in your code to break things into categories too if you needed to.

Pretty handy!

An example to get started.

//
//  Extensions.swift
//
//

import UIKit

//MARK: - UIColor -

extension UIColor {
    convenience init(red: Int, green: Int, blue: Int) {
        assert(red >= 0 && red <= 255, "Invalid red component")
        assert(green >= 0 && green <= 255, "Invalid green component")
        assert(blue >= 0 && blue <= 255, "Invalid blue component")
        self.init(red: CGFloat(red) / 255.0, green: CGFloat(green) / 255.0, blue: CGFloat(blue) / 255.0, alpha: 1.0)
    }
    convenience init(netHex:Int) {
        self.init(red:(netHex >> 16) & 0xff, green:(netHex >> 8) & 0xff, blue:netHex & 0xff)
    }
}

 

Back to iOS Development

I have been buried in Android Studio for the past several months. Learning that from scratch didn’t come without it’s challenges and brief excitement. But I’ve really grown to loath Android development for many reasons that I won’t go into here. It’s negative, so I’ll try to avoid thinking those thoughts.

I fired up the latest Xcode this past week to create a Universal iOS application for a simulation and to test out some ideas for a touch-gesture friendly device. I let out a calming “Ahhh…” as soon as the welcome file-picker revealed itself. Some complain about the tool (notably those who use Visual Studio). If I don’t need to dive into the tricky guts of things and stay floating along pretty much at the comfortable surface, the tool rocks for me. It actually makes me happy while using it.

For this project, because of the speed I need to develop, I’ve steered clear of using Swift. I didn’t want to spend the time to convert the thinking for Swift. I honestly like nearly everything about Objective-C… not caring how old the language really is. But I see the excitement and the modern Swift and I know I’ll be converting to it as my main developmental language choice. I just need to spend the cycles learning it before I develop with it. Perhaps I’ll convert a non-essential application sometime just to see how it goes.

A Mac OS X Finder trick for developers

If you’re like me and use many different tools, getting to them might take a tiny bit getting to. You might use Alfred (which is incredible), or you may use Spotlight in Mavericks or even better in Yosemite. You may use the dock. I’ve added a few alias icons to my Finder windows, and you can too.

Screen Shot 2014-09-05 at 3.12.12 PM

See those icons (Versions, Cornerstone, Android Studio, Xcode)? It’s very simple to drag them into a Finder window, and back out again when you find that you might want other alias icons there instead.

Command-drag them to the Finder window from your dock or desktop or wherever, and that’s it. Command-drag within the window to reposition them. They will appear in every Finder window instance.