Getting Started (iOS)

The SuperAwesome Kids Web Services (KWS) Social SDKs for Mobile are a set of individual composable components for easily creating kid-safe social applications for the Android and iOS platforms. They may be used in isolation to each other or composed together to create a complete social media experience for kids.

The SDKs are backed by SuperAwesome’s Kids Web Services platform, which provide APIs for authentication, content creation, content moderation, social actions (such as like, share, follow), and personalised social content feeds.

The SDKs are written in Swift 4 and use an MVVM + Redux pattern. The structure of each SDK is protocol oriented in order to provide a more scalable and consistent approach.

Composing the SDKs

To compose the SDKs into a custom user experience you can use the components (views) provided out of the box (combining UI and Data services) or create your own using the components we provide and link them to Data services.

The components provided by the UI SDK are subclasses of UIView.

The only step needed to display a view is a container, usually a UIViewController so that it can be managed and added to the stack view of the app.

Our components give the possibility to 3rd party developers to generate the entire layout of a view using interface builder, simply dragging and dropping a UIView and subclassing it selecting the requested component.

Our components have been built supporting Auto Layout to ensure the best content display possible considering the devices available on the market now.


Provides default UI for creation of new user accounts and authenticating existing users. Includes additional functionality for requesting password reset emails and generating random usernames via the KWS API.

Component implementation

public class CreateUsernameViewController: UIViewController {

   // Interface components
   internal var createUsernameView: CreateUsernameView!
   // Logic components
   internal var viewModel: CreateUsernameViewModel!

   required public init(withViewModel viewModel: CreateUsernameViewModel) {
       self.viewModel = viewModel
       super.init(nibName: nil, bundle: nil)
   required public init?(coder aDecoder: NSCoder) {
       super.init(coder: aDecoder)

The only component required from the CreateUsernameView in order to be implemented is a viewModel (for a better understanding of the role of the viewModel please refer to MVVM pattern description).

The communication between views and components is based on the delegation pattern.

In case the view is created using IB (Interface Builder) a setter is necessary to initialise the view correctly.

   // MARK: Setters
   public func setViewModel(viewModel: CreateUsernameViewModel) {
       self.viewModel = viewModel
       createUsernameView.setViewModel(viewModel: viewModel)

View Layout

To correctly display the view in its container, independently by the method chose to set up the constraints, the only one required is pinning the view edges to the container’s edges. In our implementation we use PureLayout.

   private func setUpView() {
       view.backgroundColor = .white
       createUsernameView = CreateUsernameView(withViewModel: viewModel)
       createUsernameView.delegate = self

These are all the steps necessary to build a CreateUsernameView as shown at the beginning of this paragraph.


The implementation of the navigation bar, in terms of look and feel, has been implemented by us based on our design. A custom layout can be implemented.


The base onboarding experience we implemented is based on a series of actions, or steps, the user needs to perform. A step can require one or more actions to be performed in order to be marked as completed.

OnBoardingStep Protocol

OnBoarding step represent the logic description for a list of actions expected by the user.

public protocol OnBoardingStepProtocol {
   var isComplete: Bool { get }
   var completedActions: [Bool] { get }
   var actions: [(action: ActionProtocol, isRequired: Bool)] { get }
   var completionAlertSkin: OnBoardingAlertSkinProtocol? { get }
   var headerStepSkin: OnBoardingHeaderStepSkinProtocol? { get }

Each step is fully customisable in terms of actions and look.

OnBoarding header view

This is the graphical representation of the steps described above can be seen in the above image.

The list of steps is dynamic and supports more than 5 steps. In case of 6, or more, steps the content is paginated allowing the user can scroll through them using the pan gesture.

Completing an OnBoarding Step

Once a step is completed a pop-up is presented to the user providing visual feedback.

The component shown in the image is a FlatAlertView, a custom component used to display customised full screen popup, our alternative to Apple’s UIAlertController.

As like any other component we provide, it conforms to the Skinnable* protocol making it customisable.

*Skinnable is our internal protocol to allow views to be customised providing a model which defines the look of individual components

How / When to update a step

The entire onboarding process is handled by a middleware component that listens to every action dispatched to the App store and compares them with those specified in every step.

This check will perform an automatic UI update of the onboarding header and presenting the relevant pop-up if required.



Provides default UI for displaying feeds of content tiles from users, channels or other content feeds retrieved from the KWS Social API. It includes functionality for liking and sharing content items via the KWS API, and the ability to report content to moderators. We provide support for displaying image and video content within the content tiles. Content tiles include author information, in the form of a username and user avatar, and support the presence of a text comment as part of the content.


Provides default UI to display the comments associated to the supplied feed item. Includes functionality to like and reply to comments, and to report comments to moderators. Provides support for text, image and “sticker” comments.

Video Player

Provides default UI for playback of video content. Includes functionality for play, pause, scrub, replay, and fullscreen.

Our VideoPlayer is built on top of Apple’s AVKit core functionalities. We expanded it with our own custom interface and controls.

VideoPlayerView conforms to Skinnable.

Input interface

The input interface follows our MVVM approach requiring only a ViewModel to initialize the component.

// MARK: View initializers
   init(frame: CGRect,
        viewModel: VideoPlayerViewModel,
        skin: VideoPlayerViewSkin? = VideoPlayerViewSkin()) {

       self.viewModel = viewModel
       self.playerFrame = frame
       if let skin = skin {
  = skin
       super.init(frame: .zero)

Output interface

The output interface communicates changes of state of the control view.

public protocol VideoPlayerViewDelegte: class {
   func didPressMinimise(videoPlayer: VideoPlayerView)
   func didPressFullScreen()
   func didTapCTAButton()


Provides default UI for displaying a list of results based on the keyword provided. It includes functionalities to directly perform actions such as follow/unfollow a user or a #tag.

The default state of the view shows a list of featured users and #tags.

The component is divided in to two subcomponents to maximise reusability and modularity.


This component is used to provide a user an input view where to type the any search keyword.

SearchBar conforms to Skinnable to allow customisation.


The SearchResults view will require a keyword to perform search on both users and #tags.

It takes care of validation clearing unwanted characters before keywords are provided to the search function in the DataProvider.

SearchResults conforms to Skinnable to allow customisation.

The SearchResultCell is used to display the results and conforms to Skinnable allowing customisation.

User Profile

Provides default UI for display of a user’s and account details. It includes the following functionality:

  • Showing the user’s followers/following lists.
  • Follow/unfollow the user displayed.
  • Discover new followers if the user displayed is the current logged in user.
  • Display the entire list of created content of the displayed user.


The User Profile view is composed of 3 independent components:

  1. User Header View
  2. User Stats View
  3. User Creations View

The UserView holds all of the above listed components. The only data required to populate the view, and its subcomponents, is the userId, this is used to fetch required data.

creation TOOL

The Creation Tool SDK is an independent SDK to the UI SDK, this can be used in a project by itself as a fully functioning tool, or extended in an application but taking advantage of the delegation hooks provided.

The Creation Tool SDK is fully skinnable. See here for more guidance on skinning the SDKs.

Drawing Tool

This is a basic drawing tool that allows you to draw lines on the canvas as layers. Line colour and width can be controlled from the tool menu.

We also provide a Rotobrush tool within the drawing tool, this draws the specified number of lines rotated around a circle.

This tool supports the Apple Pencil and 3D Touch technologies.

Sticker Tool

The sticker tool reaches out to the containing app for a view to provide an image picker of sorts (in this case we reach out to the StickerKeyboard in the UI SDK), images are added to the canvas as an independent image layer that can be scaled, rotated and translated.

Image Picker Tool

This tool is identical to the Sticker Tool, however it is intended to load the system image picker and provides a image layer on the canvas.

Image Saving

The canvas can be saved to disk as a JPEG at any time using a configurable resolution provided in the configuration object.

Undo/Redo support

Every layer-addition/drawing-stroke added can be undone and redone using the supplied undo and redo actions

Layer Engine

Every view is added to the layer engine, this supports redrawing of the layer stack, layer deleting, layer moving, layer insertion.

History Engine

As with the layer engine, the history engine holds a reference to every layer added and maintains the state of the canvas history, this updates the state of the undo and redo buttons.

Any questions? Get in touch!