Never done any serious development, can someone please educate me whether any of these three issues can and should be targeted earlier in development? For example is any of the first two directly going against some well known best practices? I'm judt curious, not trying to insinuating anything as I don't understand iOS development.
A lot is silly issues can be ignored in any small app, and will become big later on.
If you picked good habits from past scars, stick to them. Otherwise, concentrate on functionality, dogfooding on real devices that real people have as much as possible, and use profiling to find the bottlenecks that emerge when you find the time (since you’re focusing on functionality).
(Exceptions to this rule exist, like if your product is some cloud service then speed might be an actual functional requirement of whatever you’re building)
Using Strings in any performance-critical situation, like object identifiers, is a newbie mistake (but also extremely common). That one shouldn't have happened. The others just strike me as things one learns about and fixes as the project matures and someone bothers to do a perf analysis to find the low-hanging fruit.
…this is not very good advice? Using strings is fine, until it becomes a problem. People are going to read your comment and decide to change all their strings to integers or something at the cost of maintainability.
It's not necessarily about the size itself, but more about the fact that it has to go through a memory allocator and it has to be GC'd if that's applicable, while a simple integer doesn't. Copies are more involved too.
Using strings for identifiers is almost always a bad idea.
Not something I had considered. So for example a UI component that might load 3 different versions based on a string identifier, should instead use an enum which maps to integers? I say an enum because this would preserve readability of the code.
Do you mean an API entirely internal to your application? In that case, yes, you probably want to use integers (enums), not Strings, to choose what to display.
If you are interfacing with other APIs that use Strings, it may make sense to just pass those through. For example loading files from disk or pulling up UI classes from the OS library using some String identifier or something. It's hard to say without more context.
My guess is they are talking about some optimizations iOS does to make strings more performant, like interned string constants and tagged pointers. The majority of string usage probably falls under those.
Working with dynamically allocated strings, like reading from files, rendering from data bytes, working with C strings or building formatted strings, might have worse performance characteristics.
Basically yeah. At a super rough level of understanding, the CPU can compare two integers with one instruction, but has to loop through a whole string[1] one character at a time to compare two strings for equality.
[1] Yeah yeah, CPUs & standard libraries are smarter than that, I know, I know. You get the point.
You'll want to fix most of the problems relatively late in development, although I can't recommend enough testing on the most low-powered hardware from the get-go. It will let you know immediately when you've written slow code.
It's easier to fix a design mistake just when you've made it than when you've got six months of development hinging on the poor design choice.
Functionality first, but I'd say that you should have a healthy skepticism on third-party libraries - not a "we'll write our own instead" but a "do I really need this feature/tracking".
In many cases the time and code required to incorporate some aspect of a 3rd party lib to do something is similar to the amount of time and code in building what you need. In that case, the dependency only serves to make your code more complex (and slow).
This is not always the case, but surprisingly often.
