A new version of VoodooPad for iOS is out, the first one from Plausible Labs. Version 2.0.7 brings very few changes over 2.0.6: a couple of bug fixes and an updated Dropbox SDK. The big change is that it’s now our build, and with our build comes a new app on the App Store that customers need to grab.
The App Store originally had no way to transfer apps from one developer to another. If an app was ever purchased by a new company, as we’ve done with VoodooPad, there were only two choices:
- Give the selling company’s entire iTunes Connect account to the new company.
- Take the app down from the selling company’s account, then post it as a new app under the new company’s account, and somehow migrate all the users.
Neither option was great, but they were the only choices. The first one only works if it’s the seller’s only product, and the second one is tough on users.
This year, Apple added the ability to transfer individual apps between developers. Hooray! We used this with the Mac version of VoodooPad and it worked great.
Unfortunately, this functionality comes with a huge gotcha: if an app has ever so much as gazed upon iCloud, it cannot be transferred. I’m not clear on exactly why this is, but there is apparently some inherent technical limitation in Apple’s backend code that makes this impossible. Presumably it’s the same sort of technical limitation which prevented app transfers altogether for so many years.
While VoodooPad for iOS has never used iCloud, it did have iCloud enabled as part of an experiment, and that was enough to make it ineligible for transfer. That means we’re stuck with the two bad choices above. The first is out of the question, as Flying Meat also has Acorn on the App Store and so can’t just give us the entire account. That leaves us with the second choice: take down Flying Meat’s VoodooPad for iOS, and post our own.
What To Do
Flying Meat has posted 2.0.7 on their account, but that will be the last version there. For future updates, you must switch to our version. Since it’s considered a separate app in the App Store, you need to obtain it manually. You can do so here:
If you’re like me, you may be thinking, “But wait, won’t I have to buy it again?” Normally that would be the case, since Apple doesn’t see the two apps as being related in any way, and so your previous purchase doesn’t count for the new version. To mitigate this, we’ve made the new version free through January 21st, to give everyone time to move over to the new version. Please make sure you grab the new version now, while it’s free. Once you do this, you’ll need to transfer your documents across, since it acts like a completely new app and doesn’t share any data with the old one.
If you’re syncing with Dropbox then the transfer process is extremely easy. Just set up Dropbox in the new copy of VoodooPad and all of your documents will automatically sync to it.
If you’re not syncing with Dropbox, then I definitely recommend setting it up. It’s free, it’s easy to use, and it works great. You’ll need to set up both the old and new copies of VoodooPad with Dropbox, and then the new copy will sync the documents from the old copy.
If you’re not syncing with Dropbox and don’t want to, then you can either use WiFi sync with a Mac to transfer your documents, or you can use iTunes. Check out the documentation on syncing and transferring for more information:
However you transfer the documents across, double-check to make sure that the new copy of the app has everything, and then you can go ahead and delete the old copy from your device.
The Plausible Labs version of VoodooPad for iOS is now on the App Store, but as a separate app. It’s free through the middle of next month so that existing users can move over at no cost. Existing users need to:
- Download a copy of the new app from the App Store.
- Transfer their existing data into the new app, either through Dropbox, WiFi sync, or iTunes.
It’s also a great time for new users to check out VoodooPad for iOS, since you can also grab it for no cost during this migration period.
This is the final piece we had to take care of in moving VoodooPad from Flying Meat to Plausible Labs. We’re looking forward to being able to fully concentrate on improvements to both the Mac and iOS versions of the app now that we’ve tamed the App Store beast.
Thanks for your patience with all of this, and please don’t hesitate to contact us if you have any questions or problems with the iOS migration.
I’m pleased to announce the first release candidate of PLCrashReporter 1.2. Plausible CrashReporter provides an open source in-process crash reporting framework for use on both the iPhone and Mac OS X, and is used by the preeminent crash reporting and analytics services for Mac OS X and iOS.
This release adds support for more precise stack unwinding on ARM64 using DWARF eh_frame and Apple compact unwind metadata. As far as I’m aware, PLCrashReporter is the only 3rd-party crash reporter on iOS to support eh_frame/compact unwinding, and as such, provides the most accurate backtraces available for the platform. (See below for the technical details.)
Significant changes since 1.2-beta2:
- Production ARM64 support.
- Improved ARM64 unwinding (DWARF eh_frame and Apple compact unwind support).
New ARM64 Unwinding Implementation
On Mac OS X, Apple’s compiler toolchain includes additional metadata within each binary that can be used to perform near-perfect backtraces — whether you’ve crashed in objc_msgSend, inside of a C++ function, or even inside of a custom assembly trampoline.
Without this metadata, crash reporting implementations must apply heuristics to determine best unwind strategy, and in many cases, will do so incorrectly, resulting in incorrect or incomplete backtraces, making bugs harder to understand and more opaque.
With the introduction of ARM64, Apple has brought support for this additional metadata to iOS, where we were able to add support to PLCrashReporter. This involved reverse engineering the incorrectly documented compact unwind format (rdar://15057141 – Incorrect compact unwind documentation in compact_unwind.h), and implementing a full suite of ARM64 hand-written assembly regression tests that we used to ensure the correctness of our unwinder and compatibility with Apple’s implementation.
We’re comfortable saying that PLCrashReporter provides the absolute best crash reporting data available from any 3rd-party on-device crash reporting library for Mac OS X or iOS.
On ARM/ARM64 (ARM), the return address — that is, the address at which execution should resume when the called function returns — is stored in the link register (lr) when a function is called. This address (generally) points to the next valid instruction directly following the branch instruction.
When the called function returns, it uses the saved value stored in the link register to branch to the original caller. If the called function itself calls a function, the link register will be overwritten — thus, the contents of the link register must be saved and restored as to allow the called function to return to its own original caller. In most functions generated by the compiler, the link register will be stored in a standard location, reachable via the frame pointer — this is what a naive crash reporter will rely on to perform walking of the stack frames and product a backtrace.
Where this approach fails is when a function behaves differently than expected — such as objc_msgSend(), where it neither sets up a stack frame nor saves its link register. Objc_msgSend works as a trampoline — it looks up and branches directly to the method implementation, and once complete, is no longer relevant in a backtrace. If a crash occurs in objc_msgSend, and a naive backtrace implementation simply consults the stack where the link register is normally saved, it’ll fetch the contents of the previous function’s link register, and thus, skip a frame. The information will still be available from the crash report — you can fetch the link register from the report and determine what the caller should be — but this is hardly ideal when generating easy-to-use backtraces.
In more complex cases, the frame pointer and link register may be entirely indecipherable by a naive frame walker — for instance, if a crash occurs inside of a custom assembly trampoline that has overwritten both, or if the crash occurs inside of a managed runtime that generates non-standard native code.
To handle these cases, Apple’s toolchain provides information on the location of non-volatile register data — including the link register — and the steps necessary to access it, generating a ‘perfect’ backtrace. These instructions are provided via both DWARF unwind data, and Apple’s compact unwind encoding. The compact unwind encoding provides a strict subset of the DWARF unwinding data, while consuming considerably less space, at the cost of only being able represent a subset of the standard well-defined methods for unwinding a single frame. The DWARF format and implementation, on the other hand, is considerably more complex — it even includes a full, turing complete opcode interpreter that may be used during the unwinding process to express the location and steps to retrieve register values. The DWARF data can be used to express even the most complex and bizarre unwinding steps for a hand-written function. As far as we’re aware PLCrashReporter is the only crash reporting solution to provide full support for client-side unwinding via both DWARF and Apple’s Compact unwinding data.
We’re big fans of VoodooPad and put it to a lot of use. We’re excited to take over the reins from Flying Meat and hope that we can live up to the expectations they have set.
For the moment, existing and new users should notice few changes. For the future, we hope to be worthy stewards of the app, and maintain its spirit and quality while continuing to improve it.
Product acquisitions can be worrying to existing customers. The new owners can come in with overly-ambitious plans that end up not working out. We plan to take things slow and steady and make sure we thoroughly understand the app and its user base before we look for any exciting new directions.
We’d love to get to know VoodooPad users. If you have any questions or comments, or would just like to say hello, please write in! We’d be delighted to hear from you.