Hello everyone, I'm Brother Kun
Today, I will discuss with you a topic: how important is the stability of technology?
Last week, it took three days to get an iOS project that was expected to take at least a week to complete in the latest Xcode 15 (iOS development IDE)!
Actually, to be honest, I don't know if this iOS project will be able to run on Xcode 15 in two weeks, but the results are good.
This project has been in the past four years, and it is our company's main profitable product (rebate app), but the technology stack is still relatively old, and some rely on swift 3.0 (the latest swift version is 5.5), and it can't run on the latest Xcode 15, so it can't be packaged.
In fact, two weeks before May Day, when we were iteratively developing the product, we found that we had to use Xcode 15 packaging after 4.29, but fortunately, we found this problem a week in advance, so that we could downgrade to Xcode 14 to develop packaging first, and the iterative features were successfully launched.
But the problem that the app can't start packaging on Xcode 15 has to be solved after all, so after I came back from May Day, I kept iterating on the app to make it run on Xcode 15.
Four years is actually long and short for a project, theoretically like a Java development project, because the JDK is usually designed to be backwards compatible (compatible with old versions), the old project can usually run, why our iOS project has such a problem that it can't run on the latest version of Xcode 15.
The main reason is actually because many of the pods in this project (the pods in the iOS project are similar to the third-party dependencies managed by Maven in Java) are developed by Swift (Apple's programming language launched in 2014), and many of these pod libraries refer to OC (Objective-C, Apple's previous mainstream development language).
In the previous Xcode, the project could be run, but the latest Xcode 15 has made a lot of changes to the compiler, etc., resulting in these pods not compiling and passing, and then they can't run, and they can't try all kinds of methods on the Internet.
Imagine if you find a bug online that needs to be fixed urgently (such as not being able to withdraw), and then your app can't be packaged and can't be fixed in a short period of time, which is likely to lead to the loss of users, business stagnation, or even the company's closure.
If our technologists at the time had used OC instead of Swift to write code in engineering, there would have been no such problem, and if we had to use Swift, at least until the ABI was stable.
"Here's a quick explanation of what ABI stability is: imagine a bridge that connects two islands: one is the Swift language itself, and the other is an operating system, such as macOS or iOS. The bridge is like an agreement that ensures that both sides can understand and communicate with each other. In the world of software, this bridge is the Application Binary Interface (ABI).
Swift's ABI stability can be likened to the bridge's structure becoming solid and no longer changing. In the early days, Swift was still evolving, and the bridge needed to be rebuilt every once in a while, which meant that if developers were using a new version of Swift, they might need to recompile their application to make sure it would work on the new bridge."
Swift as a new technology, in fact, there are still a lot of pitfalls, and Hand Tao also began to introduce Swift into the project after ABI stabilized, which is like JDK 22 came out, but most of the domestic Java 8 is still used.
Why is there such a "you are promoted, you are promoted, I use Java 8" scenario, and it is not for stability reasons.
There are several factors to consider when introducing any new technology:
- Whether the new technology has significantly improved development efficiency/program performance
- Are there enough people who are familiar with the new technology (enough people means easy handover, easy to locate problems, easy to develop features)
- Whether the new technology is stable for the business in the short or long term
Generally, the importance of the above three points is decreasing, but in fact, the third point may be the most important.
In fact, although we introduced Swift before ABI stabilized, the company's development was booming at that time, with dozens of iOS and several iOS architects, so once there were any technical problems in the project, it could be easily solved.
But then the company's business took a turn for the worse, and the iOS team was laid off or left and there was no one left, and then the company completely transformed, and all the technology was wiped out, and you read that right, iOS development was all gone (who would have thought of such a situation).
At this point, Swift, which had been introduced in the project, became a time bomb that could detonate at any time.
So looking back now, if Swift hadn't been introduced before ABI was stable and had been using OC, there wouldn't have been such a problem at all.
In the past, some people complained that the banking technology stack was too old, for example, compared to JSON, which is commonly used on the Internet, the data format of banks is mostly XML, which is universal and unchanging.
In fact, it is understandable for banks, after all, it is finance, it is necessary to focus on stability, and it is good to refactor the code a few times, but due to the historical legacy of the problem, there may be technical debt, and it will be a tragedy if there is a problem such as the amount of money that cannot be correct, so really don't show off the technology, the technology is enough!
In the end, the problem has arisen, and complaining will not solve the problem, so how can we solve it?
Here's a quick overview of how I made changes to get my old project up and running in Xcode 15.
In fact, running a project is the same as everyone who is familiar with a project or business, grasping the big and letting go of the small, grasping the main line, running through the main process, and then looking at the details.
The main reason why the old project can't run on the latest Xcode 15 is that the Swift in the pod references the classes in OC, so I can comment on the logic first, and then see how to optimize it when it runs through.
Another example is that there is an anti-decompilation third-party library, and finding its existence will also cause the project to fail to start, and there is no way to get around, so just kill it, safe, compared to the fact that the app can't start This thing is not so important, this problem can wait for the app to run up and then find a way to make up for it.
When you encounter a problem, don't think about it, you can get around, don't stumble on the details, pick up sesame seeds, and lose watermelon.
For example, after the project was up and running in Xcode 15, I found that the display of several weex (a cross-platform framework) page was a bit out of order, as follows:
The first thing I thought when I saw this page was that I had to use H5 to refactor, but using H5 to refactor is a lot of work, is there any other way?
I found that not every UI on this page is actually out of order, but a few UI rendering problems, then you can analyze the difference between these few problematic UIs and other normal display UIs in weex, so after analysis found that there is a difference between the ternary operator and the writing of text, after transformation, the problem is solved, compared to the time of using H5 to refactor, this time is almost negligible.
For more information, please click Full-Scenario Live Streaming Solution - Aerospace Cloud Network Solution