With Apple’s World Wide Developers Conference (WWDC) in full swing, as part of the company’s annual festivities they have unveiled the next version of their venerable Macintosh operating system. Since shifting to free, yearly updates, the …
Today Apple made an interesting announcement for developers regarding Safari. Safari is Apple’s browser across all of their iOS and OS X devices, and the layout engine at its core is WebKit. WebKit was originally started as a project within Apple as a fork of KHTML, a layout engine developed by the KDE project. Today it’s widely employed in many browsers on many platforms, with Google and Opera formerly using it and now utilizing a fork of WebKit called Blink.
Traditionally developers who want to use the latest improvements to WebKit have had to download WebKit nightly builds, which as their name implies, are builds that reflect the latest changes to the WebKit code base and are released on 24 hour intervals. This allows developers to test and develop against new features being added to WebKit, which later make their way to Safari and other WebKit-based browsers as well. Distributing nightly builds for developers is a common practice for large software projects, but in the case of Safari and WebKit it was not ideal in many ways. For one, it essentially made the version of Safari on a computer use the new nightly WebKit back end that was installed, which can lead to annoyances when trying to compare between the existing public release and the nightly build. It also disables features like iCloud integration for tabs, bookmarks, passwords, etc, as the builds are not signed by Apple.
The Safari Technology Preview is Apple’s attempt to address some of these problems, and make it easier for developers to keep track of what changes are being made, and to submit feedback or bug reports based on what they experience. What the preview consists of is an application separate from Safari that uses a more up to date version of WebKit than what the public version of Safari that comes with OS X uses. It’s available from Apple’s developer website, and updates will come every two weeks via the Mac App Store. This makes the list of changes and additions easily accessible with each update, and because the builds are signed by Apple there’s full support for iCloud integration. Having a separate application means that comparisons and regression testing between the current official version of Safari and one with a more up to date version of WebKit can be done easily.
One important thing to note about the Safari Technology Preview is that, while the app is available from Apple’s developer site, you don’t need to be a registered developer paying the yearly iOS and OS X publishing fee to access it. Since the target audience consists mainly of programmers building websites and web applications, it doesn’t make sense to limit it to developers building native apps for iOS and OS X.
Apple is highlighting some key things that are new in the initial release of the Safari Technology Preview. The first is that it has what they claim to be one of the most complete implementations of ECMAScript 6 (ES6), which in less precise but simpler terms means the latest version of JavaScript, as JavaScript was standardized as ECMAScript and now can be considered an implementation of the standard itself.
Image source: Mozilla
ES6 comes with some key features for developers, including support for classes as part of the object oriented paradigm, iterators, and many new APIs. I am personally not a web developer, and the fact that JavaScript is just now adopting more explicit class declarations on top of the existing function prototype based declarations comes as quite a surprise to me.
Another key feature of the Safari Technology Preview is the new B3 Just-In-Time (JIT) JavaScript compiler. B3 is the new compiler backend for WebKit’s FTL JIT compiler which was introduced about a year ago with LLVM acting as the backend. At that time there was a great deal of info about the work that went into making LLVM, traditionally a production grade compiler for native applications, usable for compiling JavaScript on the fly within the constraints of something like a smartphone. Since Apple has been a major part of both WebKit and LLVM, using LLVM as the backend to achieve greater optimization of JavaScript code made sense. However, LLVM was architected as a compiler that would be used for optimizing and compiling code on large powerful desktop computers where power usage and compile times were not a large concern, as the code would simply be compiled and shipped to be run. In the context of a mobile device, you’ll be visiting various sites and compiling a great deal of different JavaScript code, and so a different strategy needs to be employed.
This is where B3 comes in. According to Apple, LLVM’s optimizations often are overkill for the task of JavaScript compilation. There are cases where it’s actually faster to just compile some lines of code and run them than to take time to optimize, compile, and then run. In these situations, there are performance gains to be made by moving away from LLVM, as you need to work on minimizing compile time rather than generating the most efficient code possible. On a high level, B3 looks at the JavaScript code that needs to be executed and decides whether it’s actually worth optimizing it or not. For complex code that may be run many times it makes sense to spend the extra time optimizing, but for small groups of simple statements it may be better to just compile it without optimizations.
Of course, a big question may be why you wouldn’t just apply tweaks to LLVM. Apple says that B3 was designed from the ground up with a focus on quick JavaScript execution, but it wouldn’t be surprising if there are ties to LLVM which already exists to provide a solid foundation.
For developers and other interested parties looking for more info on B3 there’s a post on the official WebKit blog about other improvements that have been made. They also highlight some improvements in compile time that have been observed with popular benchmarks, while also demonstrating the fact that performance doesn’t regress from the LLVM backend despite the significant reductions in compile time. Right now B3 isn’t fully ported to ARM64 and that will be necessary before we see it debuting on iOS.
The last two major inclusions in the first release of the Safari Technology Preview are an updated IndexedDB implementation and support for the newest standard of Shadow DOM. The former is a way of storing data on a client device for quick access, and the changes are the result of developer feedback, with Apple claiming that the new implementation is more stable and better compliant with established standards. A simple explanation of Shadow DOM is that it provides a way for developers making websites and web apps to better define the style of widgets and controls while keeping them independent from other styling options that apply to the page.
The Safari Technology Preview is available now from Apple’s developer website. As mentioned before, it only needs to be installed from the developer site, with future updates coming every two weeks via the Mac App Store, with the latest changes to WebKit and Safari in tow.
Today Apple made an interesting announcement for developers regarding Safari. Safari is Apple’s browser across all of their iOS and OS X devices, and the layout engine at its core is WebKit. WebKit was originally started as a project within Apple as a fork of KHTML, a layout engine developed by the KDE project. Today it’s widely employed in many browsers on many platforms, with Google and Opera formerly using it and now utilizing a fork of WebKit called Blink.
Traditionally developers who want to use the latest improvements to WebKit have had to download WebKit nightly builds, which as their name implies, are builds that reflect the latest changes to the WebKit code base and are released on 24 hour intervals. This allows developers to test and develop against new features being added to WebKit, which later make their way to Safari and other WebKit-based browsers as well. Distributing nightly builds for developers is a common practice for large software projects, but in the case of Safari and WebKit it was not ideal in many ways. For one, it essentially made the version of Safari on a computer use the new nightly WebKit back end that was installed, which can lead to annoyances when trying to compare between the existing public release and the nightly build. It also disables features like iCloud integration for tabs, bookmarks, passwords, etc, as the builds are not signed by Apple.
The Safari Technology Preview is Apple’s attempt to address some of these problems, and make it easier for developers to keep track of what changes are being made, and to submit feedback or bug reports based on what they experience. What the preview consists of is an application separate from Safari that uses a more up to date version of WebKit than what the public version of Safari that comes with OS X uses. It’s available from Apple’s developer website, and updates will come every two weeks via the Mac App Store. This makes the list of changes and additions easily accessible with each update, and because the builds are signed by Apple there’s full support for iCloud integration. Having a separate application means that comparisons and regression testing between the current official version of Safari and one with a more up to date version of WebKit can be done easily.
One important thing to note about the Safari Technology Preview is that, while the app is available from Apple’s developer site, you don’t need to be a registered developer paying the yearly iOS and OS X publishing fee to access it. Since the target audience consists mainly of programmers building websites and web applications, it doesn’t make sense to limit it to developers building native apps for iOS and OS X.
Apple is highlighting some key things that are new in the initial release of the Safari Technology Preview. The first is that it has what they claim to be one of the most complete implementations of ECMAScript 6 (ES6), which in less precise but simpler terms means the latest version of JavaScript, as JavaScript was standardized as ECMAScript and now can be considered an implementation of the standard itself.
Image source: Mozilla
ES6 comes with some key features for developers, including support for classes as part of the object oriented paradigm, iterators, and many new APIs. I am personally not a web developer, and the fact that JavaScript is just now adopting more explicit class declarations on top of the existing function prototype based declarations comes as quite a surprise to me.
Another key feature of the Safari Technology Preview is the new B3 Just-In-Time (JIT) JavaScript compiler. B3 is the new compiler backend for WebKit’s FTL JIT compiler which was introduced about a year ago with LLVM acting as the backend. At that time there was a great deal of info about the work that went into making LLVM, traditionally a production grade compiler for native applications, usable for compiling JavaScript on the fly within the constraints of something like a smartphone. Since Apple has been a major part of both WebKit and LLVM, using LLVM as the backend to achieve greater optimization of JavaScript code made sense. However, LLVM was architected as a compiler that would be used for optimizing and compiling code on large powerful desktop computers where power usage and compile times were not a large concern, as the code would simply be compiled and shipped to be run. In the context of a mobile device, you’ll be visiting various sites and compiling a great deal of different JavaScript code, and so a different strategy needs to be employed.
This is where B3 comes in. According to Apple, LLVM’s optimizations often are overkill for the task of JavaScript compilation. There are cases where it’s actually faster to just compile some lines of code and run them than to take time to optimize, compile, and then run. In these situations, there are performance gains to be made by moving away from LLVM, as you need to work on minimizing compile time rather than generating the most efficient code possible. On a high level, B3 looks at the JavaScript code that needs to be executed and decides whether it’s actually worth optimizing it or not. For complex code that may be run many times it makes sense to spend the extra time optimizing, but for small groups of simple statements it may be better to just compile it without optimizations.
Of course, a big question may be why you wouldn’t just apply tweaks to LLVM. Apple says that B3 was designed from the ground up with a focus on quick JavaScript execution, but it wouldn’t be surprising if there are ties to LLVM which already exists to provide a solid foundation.
For developers and other interested parties looking for more info on B3 there’s a post on the official WebKit blog about other improvements that have been made. They also highlight some improvements in compile time that have been observed with popular benchmarks, while also demonstrating the fact that performance doesn’t regress from the LLVM backend despite the significant reductions in compile time. Right now B3 isn’t fully ported to ARM64 and that will be necessary before we see it debuting on iOS.
The last two major inclusions in the first release of the Safari Technology Preview are an updated IndexedDB implementation and support for the newest standard of Shadow DOM. The former is a way of storing data on a client device for quick access, and the changes are the result of developer feedback, with Apple claiming that the new implementation is more stable and better compliant with established standards. A simple explanation of Shadow DOM is that it provides a way for developers making websites and web apps to better define the style of widgets and controls while keeping them independent from other styling options that apply to the page.
The Safari Technology Preview is available now from Apple’s developer website. As mentioned before, it only needs to be installed from the developer site, with future updates coming every two weeks via the Mac App Store, with the latest changes to WebKit and Safari in tow.
After last month’s “duckhead” power adapter recall, Apple has started another charger-related replacement program. Beginning today, Apple will be replacing early runs of their USB Type-C charging cable for the 2015 MacBook, covering …
Apple has announced today that they are recalling AC wall plug adapters for its MacBook laptops and iPads in select countries. The issue stems from a design flaw that, if broken, causes the AC plug to pose a risk of electrical shock if touched. The adapters were shipped outside the U.S. from 2003 to 2015 and their total number should be rather huge. Nonetheless, the number of failures known to Apple is limited to 12 cases.
Apple has found that its AC wall plug adapters (AKA “duckheads”) designed for use in Continental Europe, Australia, New Zealand, Korea, Argentina and Brazil may malfunction and create a risk of electrical shock if touched. These wall plug adapters were bundled from 2003 to 2015 with Mac PCs as well as iPads. In addition, they were also included in the Apple World Travel Adapter Kit. The company will voluntarily exchange affected wall plug adapters with a new, redesigned model, free of charge.
The affected wall plug adapters have four or five characters or no characters on the inside slot where it attaches to an Apple power adapter. The new wall plug adapters feature a 3-letter regional code in the slot (EUR, KOR, AUS, ARG or BRA). To exchange your device, you should visit a special page at Apple’s web-site.
The Verge reports that Apple is aware of 12 incidents that have occurred around broken adapters in the past 12 years. Details of the incidents are unknown; their exact circumstances are unclear too. From 2003 to 2015, Apple shipped over 120 million Macs and over 230 million iPad. The exact number of devices sold in Europe, Australia, New Zealand, Korea, Argentina and Brazil is uncertain, but it is likely that many tens of millions of AC plug adapters are potentially dangerous. On the other hand, 12 incidents that occurred over 12 years is a miniscule number. Moreover, the vast majority of laptops, smartphones, tablets, phones and players that are more than five years old are no longer in use. Nonetheless, the recall will cost Apple millions of U.S. dollars.
Meanwhile the AC wall plug adapters for the U.S., the U.K., Canada, China, Hong Kong and not part of the recall, which likely indicates that they aren’t affected by the underlying issue.
Finally, it should be noted that Apple’s AC wall plug adapters are made by contract manufacturers, such as Volex. The same producers make similar devices to other suppliers of consumer electronics.