As not every app is built the same, before implementing Taplytics, it would be a good practice to go over our best practices of how elements in your apps are built. This is to ensure maximum compatibility with the Taplytics Visual Editor and to ensure we can identify all the elements you might want to test. Here's a list of our tips and best practices:
- Use native element types
- Make sure every element has a unique ID
- Avoid having listviews inside of ViewPagers
- There are many other edge cases to list here, as with the nature of Android, but chatting with someone on the Customer Success team can help you navigate that if you've come across an element that you'd like to try to edit
- Build views off of native UIKit elements
- Use Autolayout with constraints
The major consideration with respect to using Taplytics’ Visual Editor is that it works best on static screens and elements such as copy, onboarding screens, images, pricing pages, and iconography. You also have the ability to hide elements if that’s something you want to test. When it comes to dynamic content and experiences, there may be some limitations you might encounter in terms of inconsistent behaviour.