App-o-Mat Blog

The Swift Programming Language Companion: Section 1

2020-04-23T11:58:54+00:00

In my last article I explained that aspiring iOS App Developers should start by learning swift and not jump into app tutorials.

Before you learn about UIViewController, UITableViewDataSource, and NSManagedObject, you need to fully understand let, var, enum, struct, if, for in, case let, and guard let.

So, if you know no Swift at all and don't know a similar programming language, start with Apple's Swift Programming Language book and Swift playgrounds (on the iPad or in Xcode on a Mac). Learn how to write extremely simple functions and then small sets of structs/classes that work together.

It’s important to not just read the book and type in the code you see in it. You should actively write new code based on what you learned

To help, I’ve been working on a series of articles meant to be read after each corresponding chapter in the Swift Programming Language book. Each article has a few exercises that you should be able to do in a playground based on the information in the chapter.

I also show a way to set up an active reading environment and a method for generating exercises on your own if you need to go beyond what I have provided.

There are eleven articles so far, I recommend reading them in order and doing the exercises (because they build on each other). If you know a topic well, it will just take a few minutes to get through them. They are meant to take about 30 minutes for a brand new programmer studying Swift as a first language.

Section 1

I’ll be starting on Section 2 now, so you could follow me on dev.to if you want to see the articles as they publish.

Want to make an iOS App? Start with Swift

2019-08-05T12:30:19+00:00

The biggest obstacle I see in new app developers is that they struggle with the basics.

Before you learn about UIViewController, UITableViewDataSource, and NSManagedObject, you need to fully understand let. var, enum, struct, if, for in, case let, and guard let.

So, if you know no Swift at all and don't know a similar programming language, start with Apple's Swift Programming Language book and Swift playgrounds (on the iPad or in Xcode on a Mac). Learn how to write extremely simple functions and then small sets of structs/classes that work together.

In Apple's book, I would say to at least get through these chapters

The Basics: If you are brand new, give it read, but realize that some of the topics might be beyond your grasp right now. Come back to it periodically.
Basic Operators
Strings and Characters
Collection Types
Control Flow
Functions
Closures
Enumeration
Structures and Classes
Properties
Methods

This is enough to get started. But even the simplest real app is going to have Optional Chaining, Inheritance, and Protocols. If you run into something you haven't seen yet, find the chapter where it is discussed.

Then, once you capable of writing small functions on your own, take a look at simple step-by-step app tutorials.

The iOS/Android Job Market: 2019 Update

2019-04-23T12:30:53+00:00

Last year I wrote about the native mobile app developer job market to answer the question: Should you know iOS-only, Android-only, or both. My conclusion was that:

[...] there are more jobs that require both, but still enough of a market to specialize if you want to.

and

Remember that even a little experience in your non-dominant platform would open up more of those cross-platform jobs, as I am sure the minimum requirement is a huge range. Meaning, if you were a very advanced iOS developer, and had 6 months of Android, you could reasonably apply to many jobs that require both.

So, knowing both is a little better, but not a requirement. I decided to see if anything changed a year later. You can see my full methodology on the original post.

StackOverflow Jobs

Year	Tagged iOS only	Tagged Android only	Tagged iOS/Android	Mentioned iOS/Android
2018	59	61	42	363
2019	102	159	80	784

I believe that the increase in numbers is a combination of the market size and StackOverflow's ability to get listings, so I wouldn't read too much into the increase. The more important thing is that the ratio stayed in line to what we saw last year. The percent of jobs mentioning both platforms that say they require both went from 12% in 2018 to 10% in 2019.

Indeed

Year	Title has iOS only	Title has Android only	Title has iOS/Android	Title has Mobile Mentioned iOS/Android
2018	156	211	17	197
2019	112	129	14	157

Fewer jobs in all categories, but again, this might have more to do with Indeed market-share. The important thing is the ratio. Like last year, there's an edge to knowing both, but either platform is viable on its own.

Also, like I said last year, competing to get a platform-specific job is easier if you specialize in that platform. This is especially true at the more senior levels. So, all of that time spent learning another platform would be better spent on becoming more of an expert in a single one.

But, if you want to know both, there is clearly a market for that too. I just would not add the iOS-only to the iOS/Android numbers and expect that the market is twice as big if you know both. The truth is somewhere in-between.

Dice

Year	Title has iOS only	Title has Android only	Title has iOS/Android	Title has Mobile Mentioned iOS/Android	Mentioned iOS/Android
2018	320	327	10	405	2,797
2019	232	329	13	416	2,648

Like last year, Dice is the one site I checked where the mixed iOS/Android market seems significantly bigger. The right-most three columns give different pictures. To interpret

13 jobs have iOS and Android in the title of the position
416 have mobile in the title and mention both iOS and Android in the job description
2,648 mention both iOS and Android in the job description
1,532 is the average of the last two columns

Conclusions

The iOS/Android market is bigger than either platform. The effect is most pronounced on Dice, but since Dice is a very widely used site with primarily developer jobs, it is likely that this is representative. I would not say the same for Indeed (many non-developer jobs) and the dataset from SO is significantly smaller.
Each platform is also a viable market, so while knowing both is better, it's not required
If we apply StackOverflow's job tagging rate (10%) as a measure of "requirement" we would reduce the both-platforms number for Dice to 264 -- which I interpret as:
- Jobs that mentions both might not require expertise in both
- There are some developer jobs that might just want familiarity with mobile (e.g. a devops position for the back-end of a mobile app)

Does Objective-C Block Syntax Make F'n Sense?

2018-03-27T23:34:57+00:00

You know the feeling. You're refactoring that old ViewController that’s still in Objective-C, and you get to that part where you need to extract an async call to a new class. You’ve gotten so used to closures in Swift that you're using them instead of delegates, even in Objective-C. And you say to yourself, “I know—I’ll use a block.”

Now you have two problems.

But no worries, because every Objective-C developer knows to go to F'n Block Syntax to look up block syntax, because, well, block syntax is F'd. Even after you’ve looked it up, it doesn’t stick. But I remember at one time thinking it kind of made sense, so I tried to reconstruct my understanding.

Before I was doing iOS, I was mostly a C/C++ developer, and even though the syntax for types can be complex (especially with pointers), I did find it to be consistent. C pointer-to-function syntax was probably the basis of Objective-C block syntax, so it’s worth taking a look.

To start, a C function declaration looks like this:

int add_ints(int x, int y)

This reads as: “add_ints is a function that takes two ints and returns an int.” The type of the "pointer to this function", if you wanted to assign a variable to it, is:

int (*)(int x, int y)

Essentially, you just replace the name with a *, but it needs to be in parentheses because of operator precedence and associativity. In C, the * would associate with the int and change the return type to int *.

The weird part comes when you want to declare a variable with this type. To make it as close as possible to a function declaration, we want the name between the return type and the parameters. And it turns out, we want the * to associate with that name, so we put it inside the parens, like so:

int (*func_ptr_variable)(int, int) = &add_ints;

The only thing that Objective-C did to this syntax is swap a ^ for the * to make a special operator to use for blocks (and break the association to pointers).

So, the equivalent variable declaration is:

int (^block_variable)(int, int)

So, one way to remember this is to base the declaration on C style functions (like return name(params)) and to think of the ^ as a replacement for C’s * for blocks, and then to use parentheses to associate it with the "name".

When you want to pass a block to a method, you just need to remember that Objective-C method syntax always puts parentheses around the parameter type and the name outside the close paren, so it always looks like:

-(void)doBlock:(typename)block_param

Where typename is return (^)(params), so

-(void)doBlock:(int (^)(int, int))block_param

If it starts getting more complicated than this, you probably want a typedef, and that is made exactly the same way as a variable, but with the typedef keyword before it.

So, int (^block_variable)(int, int) becomes:

typedef int (^block_t)(int, int)

And then your method can be declared as:

-(void)doBlock:(block_t)block_param

So, block syntax might make a little sense, as long as you remember:

It's kind of like C pointers to functions
So, replace the name with the pointer operator
Oh yeah, and it needs to be in parens because of C's associativity rules
Except, use ^ instead of *
And, if you need a name (for a variable or typedef), put it in the parens too (because C syntax)
But, if it's a method parameter, then just follow Objective-C style (extra parens and name outside)

And if you don't get it on the first try, just look it the F up.

Case Study: Contributing to Fastlane

2018-03-23T19:41:48+00:00

I came into work Monday to see our builds failing with a problem that was unconnected to anything we merged recently. Reading the logs, I could see that fastlane's gym was claiming that our scheme was not found in the workspace, but I knew that it was definitely there.

Note for non-iOS devs: we use Xcode to manage workspace, project, and scheme files, which are just piles of undocumented XML. fastlane is an open-source project that makes it easy to script builds, tests, and a lot of other stuff. In order for fastlane to understand a workspace/project/scheme, the maintainers needed to reverse engineer the format and build parsers.

fastlane is an incredibly fast moving project. Since they have to track (and reverse engineer) undocumented Apple things like project file formats and the iTunesConnect API, it's important to adopt their latest version pretty aggressively. So our build machine's package manager is set to download the latest release, which keeps us up to date, but also exposes us to bugs.

I saw that fastlane had released a new version that day, so I tried reverting to the one right before. That did "fix" the issue, but pinning fastlane is not a good option. I did it temporarily to get builds, but I needed a plan to get the problem fixed.

I've written that ruby is important for iOS developers to know. My reasoning was that it was used for a lot of significant iOS tooling and if you rely on open-source projects, you need to be ready to fix your own problems.

Now, I don't know a lot of ruby. I probably couldn't make a real thing from scratch with it. But I do know enough to debug and fix small bugs.

Here was my process:

You'll see that each step wasn't really that hard and you can use this is a guide the next time you run into an issue with an open-source tool you rely on.

Step 1: Read the commits

Since I knew that the issue was introduced in the latest version, there was a small set of commits to look over. One of them was to swap out bespoke Xcode project file parsing code for Cocoapod's Xcodeproj project. This makes sense, but this commit is a good candidate for introducing my problem, which was not getting a full list of schemes from the workspace.

Step 2: Do a little debugging

I really wanted to write an issue at this point, but I still did not have any idea of what was going on. Xcodeproj is a mature project and used in cocoapods, so it's not likely that this bug was for a common case. If you want your issue to be taken seriously, you should do as much as you can to narrow down the problem and describe it well. Open-source projects get tons of issues opened by people that don't do enough to make the issue easy to deal with--you can stick out by doing more (which will get your issue fixed faster).

The commit above showed this new code:

def workspace
  return nil unless workspace?
  @workspace ||= Xcodeproj::Workspace.new_from_xcworkspace(path)
end

def schemes
  @schemes ||= if workspace?
                 workspace.schemes.reject do |k, v|
                   v.include?("Pods/Pods.xcodeproj")
                 end.keys
               else
                 Xcodeproj::Project.schemes(path)
               end
end

So, if the scheme list is not complete, it really looks like the issue is with Xcodeproj. That hypothesis is easy to test, I wrote this simple script

require 'xcodeproj'
project_path = './Trellis.xcworkspace/'
workspace = Xcodeproj::Workspace.new_from_xcworkspace(project_path)
workspace.load_schemes(project_path)
print workspace.schemes

And ran it in my project's root.

It had the same problem as fastlane, which was a good sign. I read load_schemes and saw that it looks for *.xcscheme files in project directories. I did a find and saw that I had xcscheme files under the workspace folder as well. load_schemes doesn't look in that folder, though, so that was the problem.

Step 3: Write up an Issue

At this point, I could describe exactly what was going wrong and recommend a course of action, so I wrote an issue. I was still going to do more, but the point of this was to see if anyone else had a workaround or was experiencing the same thing. Many people search issues when they have a problem, so I made sure to express the core problem in the issue title so it would be easy to find.

A couple of other devs did say they had the same issue, so I tried to help them diagnose based on my findings.

Step 4: Make a simple test case

Since I knew exactly what was going on, I could easily create a workspace that reproduced the issue. I did that and attached it to the issue. I also created an issue on Xcodeproj and attached the workspace to that one as well.

Step 5: Try to fix it

The bug was really in Xcodeproj, but the fix there was not obvious to me. I decided to work-around the issue in fastlane. The fix is pretty simple--I wrote a function to read the workspace schemes:

def workspace_contained_schemes
  Dir[File.join(path, 'xcshareddata', 'xcschemes', '*.xcscheme')].map do |scheme|
    File.basename(scheme, '.xcscheme')
  end
end

And appended this list to the one created in schemes.

Step 6: Read fastlane's CONTRIBUTING.md

At this point, I was sure I was going to make a PR, so I read their contribution guidelines. I learned

I'd have to get a CLA signed by my job
How to make my local fastlane used in my iOS project (for testing)
How to run the tests
Branch and commit naming guidelines

Step 7: Make a new spec test

Luckily I had made a simple test case workspace, so I added that to fastlane's fixtures and added a simple spec-based test to make sure the new code read the workspace schemes. I actually found a bug while doing this, so I fixed that (the code in Step 5 is the fixed version).

Step 8: Make a PR to fastlane

The contribution guideline has a template for the PR message, which is also pre-populated when you open the PR. I made sure to follow the format.

Step 9: Start the CLA signing process with my job

I had to wait here, because the CLA is only sent to you after you open the PR. I then had to go through the steps at my job for contributing to an open-source project. Luckily, we were already signatories to the CLA, so I just needed to get myself added to it.

Step 10: Make a PR to Xcodeproj

By this time, one of the maintainers on Xcodeproj answered my question on what to do about the issue, so I made the PR to load workspace schemes there too. Xcodeproj has a simpler process for contributing, but I did also add the simple workspace to their fixtures and specs.

Step 11: Shepherd the PRs until they are merged

Both of these projects have automatic tests and bots responding to PRs, so I just made sure they were satisfied. I got a suggestion from a maintainer on the fastlane PR, so I addressed that.

See? Simple.

It does seem like a lot of steps, but the only hard part was debugging (did I mention how much of a ruby newb I am?). fastlane has great contributor documentation that helps getting a local development environment set up quickly. Their spec tests and code-style checker (rubocop) helped me fix issues before committing.

A snapshot of the iOS and/xor Android Developer Market

2018-02-04T15:31:17+00:00

When I wrote about whether or not iOS developers needed to know Android to be successful, I had an instinct that the answer was no, and I did a spot-check of job-boards to make sure I wasn’t way off. Here’s a more in-depth look with links so you can check to make sure it still holds at a later date (my numbers are as of February 2018).

None of the links below are location, job-level, or salary restricted. You should add those to tailor this data to your specific situation.

StackOverflow Developer Jobs

This is my favorite job site. I got my last job through it and I especially recommend it for remote jobs.

So, knowing both does give you access to more jobs, but I would say you have a better chance at the platform specific job (especially the more senior ones) if you spent your time strengthening your platform knowledge. My presumption is that your time is finite, and so you need to prioritize.

Also, note that of the 363 jobs that mention iOS and Android, only 42 were tagged as needing both, or about 12%. Keep that in mind for the next few job boards, which don't have tagging.

In either case, either or both seems like a reasonable option, but you don’t need to know both if you don’t want to.

Indeed

I have used Indeed for a more general look at the market — they scrape job sites and employer websites, so generally have more listings.

I limited my searches to the last 7 days, and unfortunately, Indeed doesn’t have a good enough search to limit to tech “tags”, so I used title as a proxy for how important something was.

If you don’t use “Mobile” in the title on the last one, you get 1,403 jobs, but it was hard to tell if this over included a lot of jobs that weren’t development or were even more general than just mobile.

So, let’s say it’s somewhere in-between, or 800 jobs (168 if we use 12% from StackOverflow). That’s significantly more than either platform, but again, it’s not as if there aren’t jobs in the platform-specific categories. This does point to a benefit of knowing both, but doesn’t make me think you need to know both.

One thing to do with these searches, is narrow them down even further to your location, salary range, experience level and other requirements to make sure it still holds for you.

Dice

Dice is one of the bigger developer-specific job boards. Like Indeed it will have more listings, and we need to use title as a proxy for a tag.

If I average the last two, it’s about 1,600 jobs (or 336 if they were tagged at the same ratio as StackOverflow), so again, significantly more. I trust these jobs to be mostly in development (or related jobs). This is even more evidence that having both is an advantage, but I still think it’s not a requirement.

Based on this data, I’d say there are more jobs that require both, but still enough of a market to specialize if you want to.

Remember that even a little experience in your non-dominant platform would open up more of those cross-platform jobs, as I am sure the minimum requirement is a huge range. Meaning, if you were a very advanced iOS developer, and had 6 months of Android, you could reasonably apply to many jobs that require both.

Do iOS Developers Need to Know Android?

2018-02-03T18:59:17+00:00

No.

That answer might be unsatisfying, but I think there’s a more important question, which I’ll get to in a moment.

Underlying questions like “Do I need to know X” is the unwritten clause: “to get a job” or “to be successful” and the feeling of not wanting to learn X if you don’t have to.

I have that feeling — I know very little about Android. It’s not that I don’t want to venture out of iOS (iOS is probably my third or fourth full-time platform switch) — it’s that I know that there is only a finite amount of time I can spend on learning other things. For my goals, strengthening my back-end skills is a better use of time (and that would be my general recommendation).

To me the question is:

When should iOS developers learn Android?

There are circumstances when full-time iOS developers should spend some time learing Android. Most of these are from my personal experience (which I have already said does not include much Android) — so, obviously, I might not know what I’m talking about.

1. If your title is Mobile X or you aspire for it to be (most likely management)

My first brush with Android was when the team I was leading was assigned to build mobile versions of our image processing tools. I already had four or five years of iOS experience, so I was very comfortable there, but I did spend some time getting to know the parts of Android we were going to use. In this case, since we were making libraries, and not apps, that exposure was pretty limited.

But if you aspire to be a “mobile” lead, manager, product manager, or leadership in a mobile-first company, you can’t afford to be a blank on Android.

2. If your iOS work is via any cross-platform framework (e.g.: Ionic, Cordova, Xamarin, etc)

My next time with Android was when I was an independent contractor and I started to get work adding native iOS pieces to Cordova projects. Since I generally became an expert in Cordova, when I looked for other work, they typically needed the Android parts done as well.

Again, this is not like Android app development — it’s Cordova plugin development, but I did need to know how to do it for both platforms. (BTW, this site started with my Cordova tutorial screencasts).

3. If you think you might want to switch to Android

This is obvious, so I’ll just list it here for completeness.

4. If you work on mobile team with native Android devs

This is the case for me now. It is really convenient for me to be able to read the Android team’s code. I do this when I have to implement something in iOS that is already in the Android version.

I already know Java which is sufficient because most of the time I’m interested in network, algorithmic, and database code (not UI, which will be way different).

Is that it?

Of course not. Hey, you might have made a game on the side and now it’s climbing the iOS charts — porting to Android seems like a good use of time (even if you farm it out, it’s good to know something about the work required). And of course, if you just want to learn Android development, then go ahead.

Do you have different thoughts about this? Get in touch.

Added later: Read the follow-up: A snapshot of the iOS and/xor Android Developer Market

Why Why Why Why Your iOS App Might Act Weird around New Year's

2017-12-09T18:40:58+00:00

Consider this snippet from a playground

let df = DateFormatter()
df.dateFormat = "YYYY-MM-dd"

df.string(from: Date(year: 2017, month: 12, day:30)!)

The result is "2017-12-30" as you might expect.

But, try the next day:

The reason is because YYYY is not what you think it is. The correct way to format the year part of a date is with yyyy. There’s a good answer on StackOverflow that explains why, but the short version is that YYYY is part of a formatting system based on week of the year, which always starts on a Sunday (EDIT: in the US, that is. Other locales’ weeks start on different days, so the exact dates that will be wrong vary by locale — thanks to dc6k and others on r/iOSProgramming for the correction)

December 31st, 2017 is the first day of the first week of 2018. If you are using the week-of-year formatting system, then YYYY is what you do to get the year part out. On other years, you might find that the first week of January has a YYYY of the previous calendar year.

So, stop what you’re doing right now and search your codebase for YYYY and fix it if you find any. You have a week or so to submit before Apple closes the App Store for the holidays.

Don’t feel bad if you find it, though. In 2013, Apple got caught with the YYYY bug and in 2014, Twitter went down for five hours because of it.

Oh yeah, this isn’t just an iOS issue. The format string that DateFormat uses is part of a standard that a lot of languages/frameworks use, so check your code no matter what it’s written in (and check your docs, of course). iOS devs do have a limited time window though because of review times and the App Store holiday.

Getting the Most out of WTF Auto Layout

2017-10-02T12:17:02+00:00

The next time you see the dreaded:

Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want

take a look at WTF Auto Layout.

It parses the list of constraints that Xcode dumps into the console and gives you a visual representation of what your ambiguous constraints are trying to do.

But WTF Auto Layout can only label the views with however Xcode decided to label them, which is just their typename by default, so you might end up with something like this:

In a simple view, this might be enough to help you, but you probably don’t need WTF Auto Layout for your simple problems. With just typenames, this isn’t going to help much.

Luckily, Xcode will use other cues from your view to pick up names. Here are other places Xcode will try to get labels for this error message:

The text in views that show text (like UILabel and UIButton).
The names of IBOutlet properties
The Xcode Specific Label in the Document section of the Identity Inspector in Interface Builder.
The constraint’s identifer property.

So, if you get an error that you are having a hard time understanding, start filling in constraint identifiers and Xcode labels to help WTF Auto Layout give you something more you can work with.

How to Learn what Auto Layout Errors Mean

2017-09-23T21:10:49+00:00

You’ve done the Stanford iOS course and all of the Wenderlich Auto Layout tutorials, but your app is still dumping

Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want

to the console every time you make a new screen.

You ask on StackOverflow, but the question gets closed because there’s no good way to paste your Storyboard into a box that wants Markdown. And screenshots are even worse.

It’s so frustrating—why can’t Xcode show a better error?!?

Xcode doesn’t really know what’s going on

Auto Layout errors are hard to understand because Xcode doesn’t know how to explain what’s wrong.

Auto Layout is a complex algorithm. All it knows is that it can’t figure out the position of a view, but it might not know why or how to tell you which view is having the problem. And when it finds a conflict in the constraints, it doesn’t really know which one is the extra one, so it removes one randomly.

But, over time, by working on a lot of constraint-based layouts, and running into (and then solving) problems, these errors actually start to make sense.

So, all you really need is practice.

But even if you work on apps full-time, you’ll spend very little time on Auto Layout, so it’s hard to get enough exposure.

You can jump start this process

One of my tips to programmers learning any new technology for the first time is to break working things on purpose.

Then, go look at the broken thing and see how it behaves. Generally, when we make broken things, we don’t really know how it’s broken, but you totally know what’s wrong this time because you know how you broke it.

So, now you can fix it.

To help with this process, I wrote EventOMat, a simple app to support a talk I gave at NerdSummit earlier this year. It implements the conference’s agenda (and can be used as a template for any conference).

But if you go to the repository, you’ll see that there are a bunch of “exercise” branches (e.g. here’s the first exercise). Each exercise branch is the full app with a few lines of code (or some part of the Storyboard) removed.

The README in each branch has hints about how to fix it. If you get stuck, you can just look at the last few commits in the branch that set up the exercise.

Make a missing constraint tutorial

You can use this app to make as many Auto Layout practice exercises as you want.

Here’s how we make a new one from the master branch.

Step 1: Choose a constraint in the storyboard

Step 2: Delete it

Step 3: Read the error and relate it to what you just did

This one is simple—it says that the Trailing constraint is missing for Label and highlights it. Your job is to put in a trailing constraint.

Don’t let Xcode make the constraint

If you click the yellow warning icon, Xcode will offer to make the constraint for you. DON’T DO THIS.

The problem is that Xcode doesn’t know what you want the view to look like, so it will make a constraint that preserves the sizes and positions that you currently see.

But we want the view to stretch the whole width, so set the trailing anchor to be equal to its superview’s trailing anchor.

Make as many as you need

I pushed the broken branch as Exercise 6 in EventOMat if you want to try it out.

But don’t stop there. You can use this app (or any working one) as a starting point to learn more about Auto Layout. Just pick some constraint and remove it. Then relate that to the error you get and fix it.

After you have done that a while, start adding in new constraints. This will probably over-specify the constraint system and cause different errors (sometimes just in different device sizes).

I have a lot more to say on this topic, so subscribe below to make sure you don’t miss more ways to learn and practice Auto Layout.