Since we are on the topic of jailbreaking firmware 2.0, I thought I would also mention that we do not have to worry about Installer not being able to run in firmware 2.0 (which is good because if Installer didn’t run on firmware 2.0 there would be no point in jailbreaking)!! RiP Dev has been giving us quite a bit of information in the last few days on what the new Installer version 4.0 will entail. And, because none of the previous applications available through the Installer will run on firmware 2.0, they have made quite a few changes to the Installer application. The following information is directly from the RiP Dev blog and it is quite the read. So, you will want to sit back and take a deep breathe before you start this one.
This post has been updated to include Part 1, 2 and 3 from the RiP Dev blog.
I am fairly sure you are all excited with the newly opened App Store (just like I am). I’ve already purchased a bunch of applications (and of course, downloaded a few for free), and I must say big “thank you” to both Apple for rolling out such a system and to the developers who put a tremendous effort into creating all these applications.
However, as you may (or may not) know, certain tools will never make it to the App Store. One example would be our own Kate, or IntelliScreen, or a bunch of others that do not wish to adhere to the strict artificial limits set to the applications for the App Store – because many of these limitations are, in fact, aimed at protecting Apple’s advantage at deploying certain new products on the iPhone, and not at the “performance and memory usage monitoring” as it is officially called.
Either way, the Installer.app will continue to evolve. In fact, the new version, 4.0, is in the final stages of development. We expect it to stay the premier tool for installing applications that do not present in the App Store, giving you best of both worlds – as it will peacefully co-exist with the existing App Store. I will publish short facts about what’s new in the Installer 4 – and, to predict some questions as to “when will it be available”, I will say – immediately or shortly after the iPhone Dev Team releases new PWNAGE.
Today’s focus is on the repository format. As you know, for Installer.app to work, it has to contact one or more repository servers – most of which are maintained by third parties. The format of the repository didn’t change since version 1.0 of Installer, and we have decided to take the opportunity and change that (since none of the software created for 1.1.4 will work on 2.0 anyway). There was two main issues for the “old” repositories: bandwidth and troubles with the compatibility. Let me elaborate.
Bandwidth usage. Whenever Installer.app on your iPhone (or iPod touch) was refreshing a source, it was fetching the whole repository listing, which can be quite large (for example, for Ste packaging it’s currently around 700 Kb). Of course, this consumed bandwidth on your end, as well as repository owner’s end – and multiplied by the number of the iPhones around, this could easily be hundreds of gigabytes of data per day.
Second issue was compatibility. You never was sure whether the package you’re downloading was going to work under your particular firmware version. Many package authors have worked around this by presenting the alert sheet to the user after the package was downloaded – which is not the optimal solution.
The new repository format solves both issues. First, it downloads much more compact packages listing from the server, resulting in over than 3 times less bandwidth. And second, the script behind the repository is smart enough to filter the packages based on the firmware version you’re using and only give you the packages that can be installed there. Nice, isn’t it?
As promised, I am continuing telling about the new Installer.
Previous Installer had another one major technical issue – it was using Property Lists (plist) files to store the database of available and installed packages. While this was very convenient for us (as programmers) as reading and writing to it required almost no effort, there was numerous complications caused by this design decision.
First, saving and loading property lists with the number of packages available across numerous repositories was long, simply because each property list file could get as large as 10-20 megabytes, and parsing that when Installer is starting up was not an instant operation. This problem was partially eliminated in Installer 3.1 and beyond when we have moved to binary format property list files from the plain XML – they take less space on disk and load and save faster.
Second, when the database with all available packages was loaded, it was kept in memory. The iPhone has strict rules about memory usage – so if you had too many sources or packages in the database, the Installer may have been closing due to not enough RAM conditions.
Third, searching through an array of, say, 1000 packages was slow – it had to run through all of them in memory one by one to find matches. Of course the ARM processor used in the device is fast, but either way that required time.
So Installer 4 uses sqlite database for all it’s stuff – which means indexing and searching is fast, the index is not loaded all in RAM and only accessed on demand. The startup is significantly faster because of that.
Next thing I am going to tell you tomorrow is how the packages itself have changed.
And to answer a common question, we’re getting there with the release – tomorrow the Installer may hit the private beta, depending on how well the work progresses.”
You can keep an eye on what is going on with Installer 4.0 on Rip Dev’s blog.
First, we have added dependencies. This means that if a particular package requires, say, Jiggy Runtime, when you try to install it, the Jiggy Runtime will be installed too (if available). If it is not available, tough luck, you will not be able to install the package – but this is for your own safety. We really don’t want to support the mess on your iPhone (or iPod touch) so Installer will make sure you got everything installed correctly.
And second, the Installer is fully multithreaded now. Which means, sources refresh, package installation can now go in parallel (and in the background, so you don’t have to stare down that progress bar at the bottom of the screen). Moreover, you can now cancel any of the tasks.
Both of these things may sound obvious, and we’re not pretending we’re inventing something new – but, rather, adding the missing functionality into the Installer (at last).
Cheers! Back to Xcode now.