Formats for NS(U)Integer: %t… (%td, %to, %tu %tx, %tX) for unsigned results NSUInteger %z… (%zd, %zo, %zu %zx, %zX) for signed results NSInteger Gerriet.

Hi, I’m trying to use NSInteger and/or NSUInteger in a InitWithFormat statement, I’m using %ld as the specifier but this is producing warnings? Has this changed recently, because code that used

My guess is that it asymmetric for historical and/or compatibility reasons. There’s also something about the Finder storing a “.Localized…” named file inside the bundle, but I don’t know if

Here the result of my investigations so far: 1. The file-system-name (shown by ls command) = PRODUCT_NAME. The PRODUCT_NAME is initially set to $(TARGET_NAME). Changing the Target Name to: “New

The problem is that Swift doesn’t have any backing stores separate from properties. As you say (if effect), backing stores are implementation details. In Swift, if a property implementation wants to

In that case I think we've gotten deeper than whether a set handler solves Gerriet's problem. I'm beginning to think there is no other good way to express exactly what he wants to do because Swift

I’m not sure I understand completely, but I think you’re missing one point. As with the base localization, which (as you say) means that Xcode treats it as the “localization” for the

Finder (at least in macOS 12.5) seems to work like this: When an app.bundle is copied into some folder (and only then), it reads TheApp.app/Contents/Resources/<system

(Also to others suggesting will/didSet) That doesn’t solve Gerriet’s problem. You can’t *prevent* setting the backing store without writing an actual setter. Similarly, if you want to constrain

I'm missing something, possibly because the example code is abbreviated. Is this not equivalent? var status: StatusEnum = .uninitialized { // Sorry, "magic number" literals // make my teeth

How about using the ‘didset’ observer? class SomeClass { var status: Int { didset(oldValue) { guard oldValue != status else { return } … do something here … } } }

You can implement a property observer instead. Here’s an example from the Swift book: class StepCounter { var totalSteps: Int = 0 { willSet(newTotalSteps) { print("About to

This has been bugging me a lot lately. I don’t know a way of avoiding the need for an extra property, and if there is, I’d be glad to hear about it too. In a way, it’s harmless, but I find it

This works (Xcode Version 8.3.2 (8E2002)): class SomeClass { private var privateStatus: Int var status: Int { get{ return privateStatus } set(new) { if new == privateStatus

macOS 12.5, Xcode Version 8.3.2 (8E2002) App with Base Internationalisation; Development Language = English, localised for German. Target = “TargetName” (probably same as PRODUCT_NAME) Both

I always wondered what this checkbox is good for. You are right: when this is checked for all custom classes in IB then the app runs as expected. As Jens mentioned I could “could update [the module

There’s an “Inherit From Target” checkbox in recent Xcodes, in the Identity inspector under the module name field. I would expect that, if checked, to cause the module name change to be picked

Changing the target name changes the product name and module name (by default unless you explicitly specify them.) The references to your Swift classes in IB still have the old module name in them.

macOS 12.5, Xcode Version 8.3.2 (8E2002), a Cocoa Swift project. Worked fine; then I changed the name of the Target from “OldName” to "NewName". Now nothing works. I get told: Unknown class

I tried that, but the problem is that, you need a lot of sub-StackViews and text is spread across them, when a resize occurs, the font sizes etc. stop being uniform, e.g. The text: Game: 123 Round: