Swift Assertions behaviour in production applications

Question

I'm reading the Assertions section in the Swift e-book and it looks like assertions work very similarly to their Objective-C counterparts. However, nowhere in the docs can I find anything about runtime behaviour while running as a production app. Objective-C's NSAssert promises never to terminate a production application as a result of an assertion failure. Is it the same case in Swift?

Ger

It would be hard to believe Swift's variant differs from its predecessor. Apple is very adamant that apps should not be able to kill themselves. Rather, the user should have control over when an application closes. – Trilateration

Answer 1

Based upon the language Apple use in their documentation, I'd say assertions are ignored in a production environment.

If your code triggers an assertion while running in a debug environment, such as when you build and run an app in Xcode, you can see exactly where the invalid state occurred and query the state of your app at the time that the assertion was triggered. An assertion also lets you provide a suitable debug message as to the nature of the assert.

And in the "Note" block:

Assertions cause your app to terminate and are not a substitute for designing your code in such a way that invalid conditions are unlikely to arise. Nonetheless, in situations where invalid conditions are possible, an assertion is an effective way to ensure that such conditions are highlighted and noticed during development, before your app is published.

Trilateration

Yes, I tried it out; assertions are indeed completely ignored if you compile your code with any optimisation switches. – Kieserite

Thanks for validating @JukkaSuomela. – Trilateration

@JukkaSuomela I have different experience - asserts are not always ignored in release builds. Please see this question for details. – Tights

can it cause any harm if we use assert in production code as well ? – Holston

@shaqirsaiyed As far as I know, asserts in production are ignored and have no effect on your application. – Trilateration

Also the the provided link it states: "The difference between assertions and preconditions is in when they’re checked: Assertions are checked only in debug builds, but preconditions are checked in both debug and production builds." So yes assert is only in debug build. – Giglio

Answer 2

The difference between debug and release is the difference between compiler arguments. The most likely answer is that there will be some special compiler settings (similar to -ea in Java).

EDIT
The Swift compiler has an argument called -assert-config

-assert-config Specify the assert_configuration replacement. Possible values are Debug, Release, Replacement.

In Release, the assertions are ignored. Not sure about the difference between Debug and Replacement.

Smithsonite

This answer is no longer valid. Asserts (not fatalError) in Swift is also based on the optimisation levels. – Harmless

Answer 3

Check your Optimization Level and make sure it is not Onone for release configuration. See my note https://github.com/onmyway133/blog/issues/39

Croquette

This is correct ↑ Also note that Objective-C and Swift Optimization levels are distinct in the configuration of your project ;) – Germen

Answer 4

Asserts are documented along with preconditions in the Swift standard library documentation.

• Debug -> Stop on assertion failure.
• Release -> Compile with assertions ignored
• Release and "Disable safety checks" -> Assume all assertion statements are statements of truth and hints to the compiler so that following and preceding code may be removed if only reached in conditions where the assertion would have failed. This means that if you follow the assertion by code on handle the exceptional case it may be ignored. If the assertion would ever have failed the behaviour is completely undefined.

I've not checked but the "Disable safety checks" may correlate with the -assert-config Replacement that @Sulthan mentions.

Unfavorable

got a link to this info? – Cantor

developer.apple.com/reference/swift/1541112-assert Also source code is now available which it wasn't when I originally answered. – Unfavorable

Answer 5

I want to point out that while assertions are supposed to be ignored in production code (based on optimization level, see other answers for more details), sometimes they are not. There has been a report about a potential compiler bug back in 2018, where one assertion was ignored and one wasn't, and I'm afraid I ran into a similar issue just now on iOS 17.5 / Xcode 15.4.

So, if, for instance, you're seeing an EXC_BREAKPOINT crash in production, and crash_info_entry_0 (at least in Firebase Crashlytics under "Keys") contains your assertionFailure message, you're not insane.

Crisper