One of the most common questions we get on the LiveView Native project is will Apple accept or reject LVN apps? The answer, on the merits of how LiveView Native works, is Apple will not reject. There are already a few LVN apps in the AppStore and so far our experience with rejections are around the typical app rejection reasons and not having to do with the nature Server Driven UI. Let’s take a deeper look at this issue and what limitations Apple has defied in their own policies as well as examples outside of LiveView Native itself.
The very first thing we should do is break away from looking at LiveView Native specifically and talk about the wider concept of Server Driven UI (SDUI). LiveView Native is just a SDUI implementation. It does not send executable code to the device. It only sends UI representation as well as events and data, similar to an API request that any normal application will make. Apple’s own AppStore Guidelines call this out in section 2.5.2.
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
This language permits the use of remotely fetching UI representation but it does not permit the fetching of and execution of code outside of a WebView. An example of a company violating this policy was DJI. In 2017 DJI shipped their DJI Go application with JSPatch which allowed the DJI Go app to download JavaScript at runtime that hot patched their application to push new runtime functionality. This is explicitly forbidden by the Apple (“may not download, install or execute code”) and resulted in DJI having their application removed until they resolved this issue.
So how does SDUI differ here if it is possibly “chang[ing] features or functionality”. There is nothing installed or executed that the client application is not already programmed to do. If you want to represent a SwiftUI Text for example you cannot dynamically call and instantiate this view, instead there has to be pre-defined definition that the <Text> UI element being sent is associated and specifically with the Text view. In other words, this allows Apple to run static analysis on the app being submitted to see if you plan to do anything nefarious with the UI coming from the server. With LiveView Native our UI tag names are 1:1 with SwiftUI. We do nothing more than what SwiftUI permits those views to do on device already.
Let’s take this a bit further with more examples of native SDUI in the wild. While LiveView Native is the first SDUI framework we are not the first to ship SDUI apps to the AppStore:
- Airbnb - uses SDUI principles via the Ghost Platform project to ship a unified UI system that can update iOS and Android applications.
- Lyft - has been using SDUI across several of their applications for the past few years.
- Shopify - Their Shop app uses SDUI
- Facebook (Meta) - Their Facebook Messenger application was re-written using Project Lightspeed which permits some SDUI functionality through React Native.
The take away here is that SDUI has been used by some of the word’s largest and most risk-averse companies for years. With LiveView Native we bring the benefits and capabilities of SDUI to the masses. As long as your application isn’t breaking the AppStore guidelines and making significant changes to the nature of your applications there is no concern for using SDUI when building native applications. For example, don’t build an application for kids, get approved and on the AppStore, then use LVN to change it to a gambling app.
In a future post we’ll discuss the benefits of using SUDI principles over legacy native application methods. For now, know that LiveView Native carries no risk when building for Apple’s AppStore. Google is far more permissive in its policies and is of far less concern. Enjoy building native apps with LiveView!
