It depends :) If, say, you wanted to have a function that does something with a string, like see if a string ended with "!" and you used it a lot. This might be a good candidate for a Category extension (similar to monkey patching in other languages).
It's easy to go overboard with this, but IMO it's a wonderfuly powerful tool.
You can still make "static" methods (called class methods in ObjC) and put them in some Util class.
What is AppDelegate's role? Other have answered this much better than I could.
Where would I put my models? Separate from your View for sure! iOS is super heavy on MVC. Your model should strive to be as decoupled from your view as possible. This makes it easy (or possible) to write good unit tests for your model.
One mental trick is to consider writing your Model in C++. You don't have to actually do this but it helps enforce how separate your model should be from the rest.
Is it more of a "one right way" or a "many right ways" culture?
I think it leans a bit toward "one right way" but it's not super strict. There is a tendancy toward protocols (equivalent to other languages), verbosity, and common design patterns.
Is Swift "culture" different from Obj C in any meaningful way?
The main "culture" difference is that ObjC is for apps that were originally written before Swift (or before Swift was a couple years old).
No one is doing a full rewrite of their existing ObjC app in Swift (at least they shouldn't be).
You can use the two together, so most new code should be in Swift (with some exceptions as always).
However, there is still a lot of apps that are mostly written in ObjC, so it's not going away anytime soon.
The only other culture difference is that ObjC is pretty loose with nil, while Swift is very explicit about it with Optionals.
What do web developers typically least understand about iOS development?
With app dev (iOS or Android), you're pretty locked into your API design. On web, if you want to add a new field or remove an existing field from some request, it's pretty easy. Update the backend, deploy the change to your web servers and done.
With app, you can have old versions of your app in the wild years later, so backwards compatibility is king.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Where do I put reusable functions?
It depends :) If, say, you wanted to have a function that does something with a string, like see if a string ended with "!" and you used it a lot. This might be a good candidate for a Category extension (similar to monkey patching in other languages).
It's easy to go overboard with this, but IMO it's a wonderfuly powerful tool.
You can still make "static" methods (called class methods in ObjC) and put them in some Util class.
What is AppDelegate's role? Other have answered this much better than I could.
Where would I put my models? Separate from your View for sure! iOS is super heavy on MVC. Your model should strive to be as decoupled from your view as possible. This makes it easy (or possible) to write good unit tests for your model.
One mental trick is to consider writing your Model in C++. You don't have to actually do this but it helps enforce how separate your model should be from the rest.
Is it more of a "one right way" or a "many right ways" culture?
I think it leans a bit toward "one right way" but it's not super strict. There is a tendancy toward protocols (equivalent to other languages), verbosity, and common design patterns.
Is Swift "culture" different from Obj C in any meaningful way?
The main "culture" difference is that ObjC is for apps that were originally written before Swift (or before Swift was a couple years old).
No one is doing a full rewrite of their existing ObjC app in Swift (at least they shouldn't be).
You can use the two together, so most new code should be in Swift (with some exceptions as always).
However, there is still a lot of apps that are mostly written in ObjC, so it's not going away anytime soon.
The only other culture difference is that ObjC is pretty loose with nil, while Swift is very explicit about it with Optionals.
What do web developers typically least understand about iOS development?
With app dev (iOS or Android), you're pretty locked into your API design. On web, if you want to add a new field or remove an existing field from some request, it's pretty easy. Update the backend, deploy the change to your web servers and done.
With app, you can have old versions of your app in the wild years later, so backwards compatibility is king.