As consumers of Apple products, and developers on Apple’s platforms, we usually watch their WWDC (Worldwide Developer Conference) event with interest – in recent years it’s been there that they’ve revealed what they have planned for the next releases of OS X and iOS. This year we’re particularly invested as the direction Apple takes with iOS could have a big impact on our work on the Bipsync Notes app during the next year. In the days leading up to the event it’s customary for developers to reveal a wishlist, so here’s three things we’d love to see happen.
1. Some love for WKWebView
In iOS 8 Apple introduced WKWebView as an upgrade for the tiring UIWebView component, which we’d previously used to power our rich text editor as it allows the execution of JavaScript to manipulate HTML. They promised drastically improved JavaScript performance, an API which streamlined Objective-C (and Swift) – JavaScript communication, and a host of other niceties.
We put it straight to use in Bipsync Notes, and found that Apple had delievered on those promises. That it lacked feature parity with UIWebView was understandable; as a first effort it was more than decent, and we assumed that further updates would address the missing features, such as an inability to focus a JavaScript element via the Objective-C bridge. All in all we’ve been bitten by the following:
-
WKWebView scrolls when contenteditable element with touchend listener is tapped (http://www.openradar.me/20871091)
-
WKWebView cannot load files using file:// URL (http://www.openradar.me/20160687)
-
WKWebView freezes main thread when restoring app from background and can lead to app killing by the system. (http://www.openradar.me/20068553)
-
Allow developers to hide inputAccessoryView in WKWebView (http://www.openradar.me/19713503)
-
WKWebView does not allow text selection with hardware keyboard in contenteditable element (http://www.openradar.me/19713813)
- Calling element.focus() from -[WKWebView evaluateJavaScript:completionHandler:] does not show keyboard (https://bugs.webkit.org/show_bug.cgi?id=142757)
iOS 8.1 came and went with no improvements, as did 8.2. With each release we became less optimistic. Perhaps the rush to get WatchKit ready was diverting efforts away from other areas? When 8.3 was released in April and again the WebKit framework was conspicuous in its absence from the release notes (it really didn’t help that WebKit shares the WK class prefix with WatchKit, which kept raising our hopes only to dash them cruelly on closer inspection!), we realised that nothing was coming any time soon.
Which brings us to the next version of iOS. Surely now Apple will take the framework forward? Well, early signs are promising. If the addition of new features like “deep linking” isn’t exactly what we’re hoping for, at least it indicates that the project hasn’t been abandoned. Searching through WebKit commits for signs of life has become a weekly ritual, but it’s been heartening to see activity there too. Indeed there are some intruiging ones, such as this one which adds support for a “fully editable WKWebView” that can “control the ediability of the entire content”.
There have been several times in the last year where we’ve seriously considered going back to UIWebView only to ultimately realise that for all its flaws, WKWebView is a major step forward that does make working with JavaScript and HTML much, much easier in iOS. We’ve our fingers crossed that after WWDC we’ll no longer consider it a poisoned chalice.
2. Even more love for UISearchController
Providing a UI for filtering a tableview has always felt overengineered to me, so when UISearchController appeared with iOS 8 to replace the now deprecated UISearchDisplayController and its many protocols, I hoped it would make filtering tableviews and the like a much more straightforward affair.
Unfortunately, while the APIs offered by this new component did make it much easier to perform searches, it has proved to be extremely buggy when used in tandem with a UISplitViewController. The UI suffers from such serious glitches in completely ordinary scenarios it does make me wonder if it was exhaustively tested by Apple prior to release – see these issues by way of example:
-
Display problems with UISplitViewController and UISearchController (http://www.openradar.me/20248565)
-
UISearchController sets wrong contentInsets when navigation bar is opaque (http://www.openradar.me/20942583)
-
UISearchController + UISplitViewController issues (http://www.openradar.me/20958663)
This is a similar sort of situation to the aforementioned UIWebView/WKWebView one, where Apple has introduced a replacement for a stalwart feature which is debatably ready for prime-time. However while in the case of WKWebView they kept UIWebView around, presumably because it still serves a purpose when WKWebView lacks key features, in UISearchDisplayController’s case they immediately deprecated it. So one is left with choosing to either use the very buggy UISearchController, or persevere with the doomed UISearchDisplayController through a sea of Xcode deprecation warnings.
Again, despite many obvious failings this component has received no attention in updates to iOS 8. I’d like to think that will change in the near future, and adding a search UI to a table can finally be a simple task.
3. Support for full text search in Core Data
Our final wish is once more search related – that Apple offer an integrated way to perform full text searches within Core Data. Given the number of apps that perform filtering of tableviews, collection views, etc. with text, I’m really surprised that to offer a search that’s barely close to what users have come to expect from applications backed by Lucene, Elasticsearch and the like, we iOS developers have to jump through hoops.
The de facto standard approach seems to be to run a separate SQLite database alongside the Core Data store which is then kept in sync with changing Core Data records, resulting in a search index that can be queried independently via direct SQLite queries, instead of Core Data fetch requests. The results of these queries can then be used to in turn query the Core Data store for actual entity results. It’s very long winded, until recently usually required us to bundle a custom build of SQLite (and still does if one wishes to use certain SQLite features like unicode tokenisation for decent diacritic-aware searches), and introduces a substantial level of complexity into the app: data migrations become more difficult, sync implementations inevitably introduce bugs, and we end up introducing another framework in FMDB just to make working with SQLite bearable.
Blue sky thinking – it’d be nice if we were able to mark a field in a Core Data entity description as full text indexed, and then Core Data would offer some NSPredicate syntax to allow a fetch request to perform a full text match against that field. Core Data has gained some really useful features since iOS 5, but they’ve been mainly to do with performance – it’d be lovely if we could now get some features that reduce the amount of code we need to write, and make the data model of our applications much simpler to conceive and understand.
Fingers crossed
There are a bunch of other bug fixes we’re hoping get fixed, but those are the three areas we’d love to see some progress in. Many developers have been calling for Apple to use iOS 9 as a chance to take stock, and smooth the rough edges that have crept in as they moved at breakneck speed over the last few years, and we echo that call.
