Tips & Tricks

The success of your addon relies on its capacity to offer a great user experience. If the end user of the app is happy, the publisher who used your addon will be happy and other publishers will choose your addon too.

Please follow these recommendations in order to keep a high quality standard for your addon.


Keep it local

All the files packed into your addon's zip file will be stored locally inside the app. That reduces a lot the loading time, which is crucial for a good user experience.

An addon is basically a web-based module embedded inside the native app. You can make your addon navigate from one local page to an online one. But you should avoid doing that unless it is really necessary. Loading online pages will increase the loading time a lot and it will make the app need an Internet connection to work.

Some modules need to download and/or send server data. That's ok, but try to transfer only app data, and keep all UI related code local if possible.


Keep it native-style

Please keep in mind that your addon is made for mobile app developers to include inside their apps. Those apps are part native, so even your addon being html based, you should try to offer a good user experience emulating native behaviour.

Sometimes Apple rejects apps that look to webby. So if publishers get their apps rejected because of using your addon, the will leave your addon a bad review on the marketplace.


Make it highly customizable

You addon is part of a full app which already has other screens that use a certain style. The publisher using your addon will probably want to customize your module in order to fit the style of the whole app. Use properties to let the publisher customize as many CSS values as possible (colors, fonts, sizes, margins, etc.). If publishers like the level of customization that your addon allows, they might use it in other apps, give you a good review and/or recommend it to other publishers.


Provide instructions

Some of the property types are only meant to provide information to the publisher (label, image, etc.). Make use of them! Keep in mind that Mobincube publishers are normally non-techies, so don't take for granted that they will know how to get an API key from firebase, because they definitely won't.

Those properties will print some information on the properties panel of Mobincube, while they are editting your addon.

You can also provide instructions inside the addon preview area or write alerts if the publisher forgot to configure something. The level of freedom is higher in this case, since you are the one developing the addon, so you have the power to decide what the addon renders on the screen. There's an easy trick to find out programatically if the addon is running on the real app or on Mobincube's interface: just check the window.parent

if (!window === window.parent){
  // This code is reached if the addon is running on Mobincube
}else{
  // This code is reached if the addon is running on the actual app
}

Make your addon multilanguage

Mobincube has publishers in more than 250 different countries. English is a quite expanded language around the world, but you shouldn't think that all publishers will understand english, because they don't. The more languages your addon supports, the more successful it will be, basically because more publisher will understand how to use it.

You should at least consider using some of the most spoken languages besides english: spanish, french, chinese, etc. Some other languages are only used in one country, so the number of people using it is not that large. But they are still important because Mobincube has a good penetration in those markets: italian, german, portuguese (Brazil), etc.


Keep it tidy

As we said, offering a high level of customization options can make your addon be great. But having a lot of options can also make the edition confussing for publishers and they might get lost in the process.

Remember that properties can be organized using tabs inside the properties.json file. So please, use tabs to group properties that have something in common: layout, texts, api configuration, colors, etc.

Inside a tab, you should also put together those properties that configure the same element.