This is the third day of my participation in the Gwen Challenge.More article challenges
preface
Last time I talked about what it takes to prepare as an iOS developer on a business level once the project starts.
This time we’ll talk about coding and technical considerations.
The soul torture continues
1. What is the minimum size of mobile phone that App ADAPTS to? Which version of iOS does App support at least?
Now basically do iPhone adaptation should be at least 4.7 inch screen, and support to iOS to which version, this is generally related to the user group, need to communicate with the product.
Generally, the default is the current version minus two versions, as the lowest version of the system adaptation, for example, now iOS14, then to iOS12, and the reason for doing this, is that apple users upgrade to iOS pretty well. There are official statistics, but I’ll say more.
Determine the minimum size of good adaptation, allows developers to avoid unnecessary UI adaptation, save energy, I have been testing feedback are somehow said his 4 inch mobile content are all squeezed together, what can I do for the UI optimization, the results checked the demand, for 4 “don’t do fit, now that there are black and white on the demand, then must adhere to don’t write the code as far as possible don’t write.
Deciding on the lowest iOS adaptation allows you to throw away some historical baggage, embrace better, more modern apis, and avoid all sorts of if-judged versions.
2. How many environments does App have?
In general, there is at least a Debug and release environment.
At some of the larger manufacturers, the environment is more.
Managing multiple environments, multiple baseurs, switching quickly, seemingly small things, actually big things.
I personally use Other Swift Flags and it’s not too fancy.
In addition, this configuration item is best decided at the beginning of the project.
3.Swift VS Objective-C
This may be the core problem in iOS projects. The choice of language determines the following coding, iteration, maintenance and selection of third-party libraries.
Things that go along with the App’s life cycle also determine how much developers make.
New project, please select Swift! Swift! Swift!
It’s so important that it should be repeated for three times.
It’s 1202, if the new project is still doing OC, it’s really not worth it.
You might say, you only know OC, learning Swift takes time and cost, and in this day and age, iOS development only knows OC sounds crazy, unless you get to a level of OC.
My personal opinion is that depth can not be reached, at least take breadth to fill, learning a programming language to reach the ceiling or not to learn, stop here is better to open a window to embrace the world.
Swift is a very modern language that is simple, easy to read and efficient. Even if you learn Swift, you have at least a potential understanding of Kotlin and Flutter. Python and TypeScript also have a little bit to do with it.
Swift5 has been very stable. I got in touch with this language from Swift2 and upgraded it to Swift3. It was a sleepless night for grammar adaptation.
Swif4, which has been upgraded from Swift3, is a little better, with many in red.
But with Swift5 it’s basically a problem, and you won’t have to spend too much effort on language adaptation upgrades.
Swift has rich open source libraries. Thanks to the advanced grammar of Swift, there are some open source libraries of Swift that OC cannot do, such as RxSwift. I have never heard of RxOC, although we have ReactiveCocoa in OC era, with the release of Swift, This framework has also been rewritten with Swift. There are also many libraries that are unique to Swift, so why not use more wheels and fewer brain cells?
Of course, I’m not saying that OC is useless and justified. OC will live and coexist with Swift for a long time, as some classic libraries also only have OC versions, not Swift versions.
Swift and OC are a long process in Cocoa. Using Swift to refer to OC frameworks that are stable and easy to use is simple and friendly. For example, I still use MJRefresh and MBProgressHUD a lot, because they are really neat and easy to use, even though mJ_ is not Swift.
Of course, it should be noted that the mixing of Swift and OC will lead to larger IPA packages. However, I think in the current era of 64G, a small package size will not affect users unless KPI is tangled. Besides, there are many other factors in this package size besides the mixing, and there is room for optimization.
I personally recommend Swift to bridge OC module, and now in XCode12.5, there is no need to generate a. H file to bridge OC library, directly import from. Swift file, which is much more convenient than before.
It is also important to note that I do not recommend introducing Swift written libraries into an OC project, because Swift has some features that are not available in OC, such as parameter enumerations, which may not be used in OC if the bridged Swift library has them.
At the end of the day, both Swift and OC have their own strengths and weaknesses, but OC is old and Swift is in the future, so embrace the new language so you don’t have to jump too far across languages.
4. Does the App need internationalization?
If there is a need for internationalization, planning and configuration should be done at the beginning of the App, which will reduce a lot of mechanical things.
I once finished an App, and then the leader suddenly pounded the table, to go to the international market, do internationalization, that sleepless night was blood and tears.
5. Which App permissions are required?
In terms of App permission development, I saw the following comments in a Domestic Android App that participated in a foreign laboratory test:
In China, an App wants to apply for all permissions, regardless of whether it uses them or not, while in foreign countries, on the contrary, the App only applies for the permissions it needs.
Although Apple is still quite strict in this aspect in the review process, and even rejected developers’ apps because of permissions.
Still write oneself weigh nevertheless had better.
6. There is no point 6
The second and third days are written some experience talk, although the summary is not systematic, but for the time being.
If you have any thoughts about the preparatory phase of the project as you read, please share them in the comments.
I’ll start the next article by going through some of the commonly used Swift libraries, so I’ll continue tomorrow.