ios-factor / ios-factor.com Goto Github PK

Given how most continuous integration works and most recently how Github Actions approaches to installing tools could developers delegate this job to the CIs?

open for discussion

Suggest adding articles about security such as HTTPS, cert pinning, etc.

Right now we just say "see section x"

Ideally a smart one like Google Docs

For tomorrow morning

e.g. Xcode not being containerized

Thanks a ton for putting this all together, this is an amazing resource and super helpful. One thing that I had a question on was regarding Veertu.

There is a mention of it here: https://github.com/ios-factor/ios-factor.com/blame/master/_i18n/en/factors/deployment.md#L11

Upon reading this line, I got super excited of a possible open source solution where we could run our own Mac OS X build servers on Digital Ocean or something similar. At first glance it looks like it is a commercial product only (understandable that developers need to eat too). Doing some additional research, it looks like they may have had a solution back in the day that was on the "open source with commercial support" model, but I couldn't find that on their current website.

Few questions & suggestions:

1. Does Veertu have an open source version? If so, maybe provide a better link explaining the different options between open source and commercial support.
2. Is Veertu a commercial product only? If so, maybe make that clear on Line 11. You might want to also clear up if they are a sponsor or not (some people get salty & hesitant with commercial referrals).
3. Does Veertu require Mac OS X hardware? If so, then maybe emphasizing that again will make it clear to the reader.

Looking forward to hearing your thoughts and any other suggestions.

I'm just tossing out this idea as I think it might be a good for ios-factor.com.

It should be possible for the server to make the app stop working (or prompt the user with a warning) if there is some serious vulnerability issue with the installed version.

Every API call to the primary backend-server should send the following values

app_version (1.0.0)
app_build_number (f477d3b)
device_model (iPhone1,1)
os_version (10.11)
app_identifier (com.ios-factor.app)
system_language (nb_NO)

Use names of your liking. We pass these values in request headers, but do as you like. The server should then be able to respond with http code 403 or the server may tag a long a warning using for example response headers. The error returned from server should state that the app needs to be upgraded because of a security vulnerability and in what way users are affected. We use the terms suggest upgrade and force upgrade.

tooling like react native: how do you sync the native code with the JS code

It's rather complex to get it right, as you need native code as well as JS code

I'm a big fan of having a .xcode-version (or .tools-version for asdf users), but I want it to work with or without fastlane.

I'm the author of chxcode which can automatically change the current Xcode for the current directory based on the presence of .xcode-version. It's mostly written POSIX sh compatible and supports bash and zsh.

Is this something y'all would consider including?

Travis seems broken right now, as they tried to merge the 2 services. I currently have to manually trigger a deploy

Just like Ruby, Python can be used for tooling iOS apps. To have instructions regarding this subject would be great!

Python is a great language for checking project consistency as a build phase. For example, at my work we use Python to write a script that we run as a build phase before compiling the code to check if there are assets in storyboards not present in xcassets.

Our setup for python dependencies uses pipenv . This allows us to work with the same version of python and install its dependencies easily, similar to ruby bundler.

Developers should track and audit dependencies they use. This can be a daunting task with quite a lot of manual work. NPM recently got npm audit which makes this a lot easier for npm dependencies.

A written suggestion for best practices regarding how to track and audit dependencies for ios would also be useful and fits well with practices for deployment.

There is a very detailed article that explains the idea of "Semantic Versioning" at https://semver.org/
Especially when you need to deal with "internal versioning" from a nightly-build system, you simply append a "pre-release identifier".
We consider this as "best practise". ;-)

Cheers, Andy

Hi!

Just a quick question regarding the following wording on the versioning page.

Build number (CFBundleVersion) - shown as Build in Xcode: an incrementing number following semver

Is it really considered good practice to use semver for the CFBundleVersion? In my experience this is usually an integer that's incremented in arbitrary intervals (based on builds or commits or whatever). Using semver for the CFBundleShortVersionString seems like a more sensible choice.

The rest of the page reads as though it's meant that way as well, I just stumbled across the mention of semver at that point.

If it's not meant that way I can gladly submit a PR and try to word that section a bit differently 😊