Now available: SDKs for native mobile app integration

With 72.9% of global ecommerce taking place on mobile devices, many companies want the same control over traffic for their native mobile apps as they do for their websites.

But just like with websites it is difficult to scale native mobile apps to handle sudden surges in users. Native mobile apps could have unique and potentially more performance bottlenecks than a website flow, and the infrastructure the app runs on could have lower thresholds. Integrating a virtual waiting room into a native mobile app is unique, as it requires SDKs that work with the leading mobile operating systems like Android and iOS.

It is also important that app visitors have a seamless user experience, with mobile-responsive waiting room pages embedded within the app itself. If visitors do leave the app or lock their phone, they should maintain their spot in line.

It would be helpful to give companies control over app traffic to prevent crashes or slowdowns from demand spikes and to treat visitors fairly in cases of limited-inventory product sales like sneaker releases or concert ticket onsales.

To help you control traffic peaks and treat visitors fairly on native mobile apps just like you would on your website, Queue-it has introduced mobile SDK integrations for our virtual waiting room. Queue-it currently offers mobile SDKs for iOS, Android, React Native, and Cordova/Ionic. All the features of web-based waiting are supported with these native app integrations.

Once the integration is in place, your app calls a function in the SDK to show the waiting room, based on the settings and traffic thresholds you configure. The waiting room appears in a mobile app as a page in a modal view, so visitors cannot browse other views in the native app while in the waiting room. Visitors will see the same, mobile-responsive branded waiting room with wait information as they would if they were on a computer or in a mobile web browser. Alternatively, you can place mobile app visitors into a separate waiting room with a faster or slower throughput, depending on your infrastructure and business needs. Visitors can browse other apps on their phone while they wait, or lock or turn off their phone, all while maintaining their same place in line. When visitors’ turn comes, the SDK will notify the mobile app by raising an event and the modal view will then be closed, allowing visitors to continue their journey in the app.

You can choose whether the SDK code runs on the client side (i.e. in the app) or on both the client and server side. The server-side integration removes the possibilities of visitors manipulating client-side code and potentially skipping the waiting room. The server-side integration also protects your mobile APIs. Below are two use cases exemplifying each.

Integration approach 1: State management on the app (client-side)

You can choose which portion of the app is covered by the virtual waiting room (e.g. the entire app, specific product pages, or the checkout flow). When the visitor navigates to this portion of the app, the client-side code will check in with your configurations whether the visitor should be shown the waiting room. If yes, the SDK will be called with the alias of waiting room and a modal view will be shown to the visitor. The visitor cannot access other parts of the app until it is his or her turn. The app will be notified by a callback when it’s the visitor’s turn. This will close the waiting room page and the app will store the state with a TTL, letting the visitor navigate the app until the state becomes invalid, such as when the user session expires.

Integration approach 2: State management on the server (server-side)

This more advanced integration first checks for the existence of a hashed token to determine if the visitor needs to enter the waiting room. The integration then also continually validates visitor sessions using the hashed token to ensure they’ve already been through the waiting room. Both functions happen on the server side, giving you added flexibility and security.

When a visitor who hasn’t been through the waiting room navigates to the protected portion of the app—for example by clicking on the “Add to Cart” button—the request to the backend API will not contain a hashed token. The server will respond with the name of the waiting room, and your client-side code will need to call the queueit SDK with the name of the waiting room. Then the waiting room will be presented to the visitor as a modal view which will prevent the visitor from continuing the journey until it is his or her turn. When it is the visitor’s turn, the SDK will raise an event with a hashed value called “queueittoken”, which the client-side API will provide to the server. The server will then validate the hashed value using a secret key, and if valid will return a hashed session and TTL. The visitor can now browse the app unimpeded because with each API call the hashed session is passed to the server, so the server knows the visitor has already been through the waiting room.

For mobile SDK integration documentation, visit our the Native App section of our Connectors page.

Queue-it offers native app SDKs to use the virtual waiting room in your Android, iOS, React Native and Cordova/Ionic-based mobile apps. The SDKs use a modal view to prevent visitors from accessing the protected portions of your app until they have passed through the waiting room. You can choose to place visitors in the same waiting room as your desktop/mobile web browser visitors, or you can choose to place app visitors in a separate waiting room according to your technical and business considerations.

For support setting up your native mobile app integration, contact your Queue-it support representative at support@queue-it.com .