Xcode on blog.iankulin.com

Why?

Wed, 26 Oct 2022 00:00:00 +0000

Why do I have to resize this preview window every time I open Xcode?

Purple warning - "Publishing changes"

Fri, 21 Oct 2022 00:00:00 +0000

It’s a pretty safe bet that if Xcode is saying there’s an error in my code, that it’s correct, and I am in error - not Xcode. Today I came across a situation where that might not be true.

I think the purple warnings are problems detected at runtime - I’ve heard of thread problems causing purple warnings. The error I was getting was “Publishing changes from within view updates is not allowed, this will cause undefined behavior.”

The error was on two lines in my model where I’d called a method to update the model from a button press in a sub-view function.

After poking around to try and work it out, I found this clear blog post from Donny Wals and it turns out it’s possibly a bug in XCode 14. My situation fitted the description - calling the method from a button in a list, and the temporary workaround of adding a modifier to the button eliminated the warning.

I’m on Xcode 14.0, and I gather from Donny’s post that the problem might have been fixed in newer versions.

Here’s the calling code - a button in a list, with the “fix” on line 25.

 func habitView(habitItem: HabitItem, habitsCollection: Habits) -> some View {
 HStack {
 VStack(alignment: .leading) {
 Text(habitItem.name)
 .font(.headline)
 Text(habitItem.lastDone.formatted(date: .abbreviated, time: .omitted))
 }
 Text(" (\(habitItem.timesDone))")
 .font(.largeTitle)
 Spacer()
 Button {
 if !habitsCollection.markAsDone(habit: habitItem) {
 print("Unexpected error - habit not found in collection:\(habitItem.name)")
 }
 } label: {
 if habitItem.due {
 Image(systemName: "rectangle")
 .font(.system(size: 40))
 } else {
 Image(systemName: "checkmark.rectangle")
 .font(.system(size: 40))
 }

 }
 .buttonStyle(.bordered)
 }
 }

SwiftLint

Mon, 10 Oct 2022 00:00:00 +0000

I was watching a Tim Ruscica video about the things that highly effective developers do, and it called to mind a book I read years ago called Code Complete. It is the only book I ever owned that I immediately purchased the new edition when it came out. It was about the meta stuff around programming that is the difference between coding and developing. In particular, it got me invested in source control and testing.

If you’ve been reading along, you’ll know I am keen to leverage the great tools available to support quality software development, and one I haven’t tackled till this week is a linter.

Linters are tools to enforce (or at least suggest) rules to improve your code that are not strictly necessary (the compiler hasn’t enforced them) but they make your code better, or at least prettier, in other ways. I gather the most popular linter for Swift is SwiftLint.

I installed it by downloading and running the .pkg. Then in any Xcode projects you want to use it in, you go into Build Phases for the current Scheme in your project and add a new script that runs SwiftLint on the files in the project’s folder. There’s a good step by step here by Vineet Choudhary. You should end up with something like this:

Now when you Command-B to build your project, the linter will run and (especially the first time) add some extra warnings and errors.

SwiftLint has many rules. Some are default rules (these are the most widely accepted ones) and some are optional. Turning rules off or on, or altering their parameters is done using a swiftlint.yml config file in the top level folder of your project.

Here’s an example from mine, where I want to alter a rule:

vertical_whitespace:
 max_empty_lines: 2

There’s a rule called vertical_whitespace. It throws a warning if there is more than one consecutive empty line in a file. I use two line gaps all over my code to signify a separate method or function, so that does not work for me. The config change above changes it to allow two empty lines. This same config file can also be used to disable any of the default rules, or enable any of the optional rules.

Rules can also be disabled and enabled in your code with special comments. For example, in my tests, I have enormous multi-line strings which don’t follow proper indentation for a deliberate reason, so at the top of this file I have:

// swiftlint:disable line_length
// swiftlint:disable indentation_width

You can turn rules back on as well. For example in this code snippet I have code that the linter wants me to write as a trailing closure, but I’m not sure how to do that in this situation yet - so I turn the rule off before it, then back on.

func stripSpaces(_ codeLines: String ) -> String {
 // break into lines
 var lines = codeLines.components(separatedBy: "\n")
 var minCount = Int.max
 // step though the lines and count how many spaces, save the minimum amount
 for line in lines {
 // swiftlint:disable trailing_closure
 let leadingSpaces = line.prefix(while: { $0 == " " }).count
 // swiftlint:enable trailing_closure
 minCount = leadingSpaces < minCount ? leadingSpaces : minCount
 }
 // step though the lines again, and trim the min amount from each line
 for index in 0..<lines.count {
 lines[index] = String(lines[index].dropFirst(minCount))
 }
 // stitch it back up
 return lines.joined(separator: "\n")
}

My strategy with the linter was to turn all the optional rules on, then run it and go through to consider each of the optional rules I’ve transgressed to decide if it makes more sense to me to change the code or eliminate the rule.

Testing, testing

Sun, 09 Oct 2022 00:00:00 +0000

I have unit testing in my goals, and if I’m going to throw this space trimming macOS utility up on the web, now might be a good time to figure out how to add unit tests to a project, how to write them, and how to run them. XCode is well set up for this, so it’s really no drama to do.

Although I haven’t worried with any unit testing up to this point in my iOS/Swift learning, in my previous programming work I did a lot of work with the large calculations involved in translating GPS coordinates and robotic positioning models where errors would be bad - so I’ve written a lot of tests over the years. I’ve also definitely felt the confidence you can dramatically refactor code with when you know the code has a robust test suite. I’m a big fan.

Adding Tests to Existing Project

In Xcode, with your project open, you need to add the testing target. File | New | Target... then scroll down to find the Unit Testing Bundle. When you add that, you’ll see a new folder in the Project Navigator, and a new source file - both with the name <app name>Tests.

If you click into the <app name>Test.swift file, you’ll see a couple of methods for setting up the testing environment and cleaning up after it. They are called before and after each test - you’d use them if you needed to set something up like some files in a directory or similar and wanted to ensure it was not affected by the tests run before the current test. Don’t worry about them for the time being.

Writing Tests

Before we can write any tests, we need to import any modules with the code we want to test. In my case, I want to test the function stripSpaces() which is in the ContentView of my app called CodeTrimmer. So in the top of the CodeTrimmerTests.swift file, under the other import, I add the import:

import XCTest
@testable import CodeTrimmer

Then we can write our tests. The test functions must start with the magic prefix test so that Xcode treats them as such. The usual approach in the test is to call a function with some specific input, then test the output is what is expected with a special test version of assert():

Here’s a couple. My function stripSpaces() deletes a number of spaces from each line of a block of code such that the block becomes left aligned. if the XCTAsserts() pass, the test passes and I get a green tick. To run the tests I just click in the breakpoint gutter next to the function declaration.

 func testStripSpaces01() throws {
 let testString =
 """
 single line string no spaces
 """
 let resultString = stripSpaces(testString)
 XCTAssertTrue(resultString == testString, testString)
 }

 func testStripSpaces02() throws {
 let testString =
 """
 single line 4 spaces
 """
 let resultString = stripSpaces(testString)
 XCTAssertFalse(resultString == testString, testString)
 XCTAssertTrue(testString.dropFirst(4) == resultString, testString)
 }

Where's My App?

Sat, 08 Oct 2022 00:00:00 +0000

The iOS apps I’ve been making, can only run in the simulator or on my tethered device (which I haven’t actually tried yet), but the MacOS app I made today, in theory could be zipped up and distributed to the world from my website. At the very least, I wanted to drop it into my Applications folder so I could use it, so I needed to find the .app “file”, and realised I had no idea where it was. If that’s your situation, then here’s the steps you need.

First of all, you are currently building debug versions of your app. We need to create a new Scheme for the release build. In Xcode use the menus to go to Product | Scheme | New Scheme…

Give it a sensible name - maybe <app name> Release or similar. Then Product | Scheme | Edit Scheme and on the Info tab, change it to a Release build.

Build the app (Product | Build ), then back in the Product menu, there’s an item “Show Build Folder in Finder”. Click on that, and there’s your different builds. In the Release folder will be the .app file that can be copied into your applications folder.

I’m not actually sure if this is a file, more likely a folder that MacOS is pretending is a file. If you right click on it and select “Show Package Contents” you can see the actual files inside it.

Customizing the default About dialog for MacOS apps

Fri, 07 Oct 2022 00:00:00 +0000

The default Xcode MacOS targeted app has a built in “About” dialog called up from the “About ” menu item in the Mac menu bar. It wasn’t immediately clear to me how to customise this, but after digging through some MacOS apps on GitHub, here’s the answer.

When you app is being built, it looks for the file “Credits.rtf” in the app bundle. If that is found (or “Credits.html” or “Credits.rtfd”) it’s used to build out the About dialog along with your app icon.

After you’ve created the “Credits.rtf” file, you need to drop it into the folder for your project where the source files go. Then in Xcode, add it to your project in that inner folder:

Then when you rebuild the app, it will show in your about dialog.

Gitting Xcode to Push

Fri, 30 Sep 2022 00:00:00 +0000

I’m very comfortable with doing all the routine git stuff from the command line, but it was bugging me that I hadn’t for the Xcode integration working. I was able to commit locally with no problem from Xcode, but could not push up to Github. It works fine from the command line, so the error about the change to a stronger SSH authentication didn’t really make sense to me.

ERROR: You’re using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.

This post from pasllani on the Apple Developer forums was super helpful, the only thing they missed was that you need to restart Xcode before it will work. The steps were:

Generate a new ECDSA SSH key with ssh-keygen -t ecdsa -C "IanKulin@kulin.com.au"
Copy the key to the keyboard with pbcopy < ~/.ssh/id_ecdsa.pub
On Github, add the new SSH key, and while you’re there, generate a new Token in Developer Tools
In XCode, delete your github account, then recreate it specifying SSH and choose the ECDSA key. It will need the access token at this stage.
Restart XCode

Other git/Github posts

Intro to git - Gitting Started
Common git commands - Gitting the Hang of it
Merge vs rebase
Create an Empty Folder on Github
Download a Directory from a Github repo
Download a File from Github

Don't Use Stupid Project Names

Thu, 22 Sep 2022 00:00:00 +0000

I’m up to Day 32 of 100 Days of Swift UI, and although the tutorial is named “Project 6” it’s not really a project that becomes a simple app, it’s really just a series of tutorials on animation that I assume the techniques, but none of the code, will be used later in apps.

I do find there’s some value in typing in the code (rather than cutting and pasting, or just passively watching) so I opened up Xcode to follow along. There not being an app name offered, I used “Project 6 - Animation”. XCode seemed happy enough with that, and created the directory and placeholder, but then refused to build it saying there was seven errors involving the __PACKAGE_NAME macro and a missing }

I did a do-over with a project name of “Animation” and it works just fine. When I updated to XCode 14 I didn’t keep the previous version, so I’ve no idea if letting the user do this is an introduced bug or not. The culprit is the ‘-’. Projects with just a space in the name work fine.

Since a google of the first error does not pull up any hits, I’ll paste it in here for future travelers giving their projects names with dashes.

'___PACKAGENAME' is annotated with @main and must provide a main static function of type () -> Void, () throws -> Void, () async -> Void, or () async throws -> Void

As far as I can make out, that is part of the boilerplate creation process and should have been replaced. Likely the dash and the spaces are all replaced with underscores to make a valid app name and the triple underscore has a magic meaning of some kind.

Recording the Simulator

Wed, 21 Sep 2022 00:00:00 +0000

I’ve been using Quicktime to screen record the preview or simulator to document my work here and in Github ReadMe’s, but thanks to this excellent short post by Sarun W, I now know it’s possible to do that directly from the simulator, including capturing gestures, and exporting to animated gifs!

Changing Xcode Font Size

Tue, 20 Sep 2022 00:00:00 +0000

I’ve been changing the Xcode font size by going into the preferences, themes, then selecting the different content types and changing the font size.

I guess I could speed that process up by saving some themes with different text sizes, but I’ve noticed a few times in tutorial videos that there must have been an easier way. It turns out that Ctrl + “+” and Ctrl + “-” increases and decreases the code font size.

I’m not sure why I need to change the font size so often, but it was bugging me, so I’m glad to find there’s sensible shortcuts for it.

How to upgrade XCode and Swift

Sun, 18 Sep 2022 00:00:00 +0000

With the September release of XCode 14 and Swift 5.7 it was time for my first update - I looked in “About” for an update link but there wasn’t one - so if you’re as dense as me, the tip is to head to the Mac App Store and have a look at the Updates page.

Your current XCode version can, of course be found in the XCode | About dialogue. Mine was on 13.4.1. There’s a couple of ways of finding the Swift version - If you’ve got an XCode project open, click on the .xcodeproj in the explorer,and have a look in Build Settings for Swift Compiler - Language for the major version.

Or for a bit more accuracy, try xcrun swift -version at the command line. I got a few errors, then the version 5.6.1

I won’t bang on about the changes for XCode or Swift since that’s already been done well elsewhere, and the Swift changes are mostly beyond my expertise level.

Xcode Refactor/Rename

Sat, 30 Jul 2022 00:00:00 +0000

This is cool. You can right click on a variable (and I guess any other) name and change it everywhere. No more tedious search and replace.

Xcode Tour

Sun, 24 Jul 2022 00:00:00 +0000

If you need a solid tour of the basics plus of Xcode, this is a great video from Karin Prater. Its the first video in her “Design-oriented course on SwiftUI”.

Instant Errors

Sun, 10 Jul 2022 00:00:00 +0000

I’m loving how, in XCode and Playgrounds, it’s constantly sort of compiling or interpreting in the background so errors are being flagged as you’re working. I tried to google the proper name for this but it’s clearly so unremarkable as to be un-remarked on. I guess maybe it’s a commonplace feature of modern IDEs, but for someone who literally used to go to make a coffee when compiling a medium size Clipper or even years later Visual Studio C++ project, it’s a revelation.

It’s so built in for me to think of errors as failures, that at first it was a quite unnerving. I was thinking “Hang on, hang on - at least let me finish typing before you judge me!”. But increasingly, I love the little second or so pause when I finish a section and wait for it to clear all the errors.