@alirtariq Thank you so much, Ali, for your feedback! We have some features like this on our roadmap. So basically the idea for long-run strategy is not just showing "The problem is there" but to show "The problem is there and here is how you can fix it" automatically. With exact offset for some element or with exact color based on the design (as a single point of truth). So you as a developer can just click on the appropriate buttons (like in the Xcode when you made a typo or chosen wrong object type. I'd call that "Quick Fix" button) and solve all problems in your UI implementation. It's not exactly a code generation. We had some kind of code generation in our first product iteration, but that didn't work out because of following reasons: - Everybody writes code differently, with different styles, different patterns, and approaches - "Code vs Storyboard" 🙂 - If the code snippet is too simple, it isn't so useful (like code snippet for UIColor, UIFont or CGRect) - Developers doesn't usually believe in automatic code generation for the whole UI layout. If you have any more suggestions to us or feature requests – I'd be very glad to hear them 😊 Thank you again!

@yaroslavazhnyuk Thank you so much, Yaroslav and a whole @petcube team for your support! 😊

@geek_1001 @yaroslavazhnyuk We love @petcube too :) Petcube Mafia will conquer the world!

@iamtekeste Thank you, Tekeste, for such honest feedback! 😆

@iamtekeste this was the most funnies comment ever!

@druh_opryshok Thank you so much, Igor!) 🚀

@druh_opryshok keep rocking! Still, so much stuff to do ^_^

@karstetter Thank you, Scott, for all your support! 😊 We really appreciate it!

@karstetter You are our lovely first user 💗

@fo0x Thank you, Artem! 🙂

@lekstwist Thank you! 😊 I'm glad you like it 🙌

@kunalslab Thank you, Kunal for supporting us! 😊 Sure, I'd be glad to share it with you. As mobile development as a whole industry evolves with new devices and new form factors – there is still a huge gap how to make all of those products for all of those devices polished enough. We believe Flawless potentially can solve the much bigger problem of the visual quality control (and in the long run strategy, a bunch of other aspects of quality factors. Not just for iOS, not just for mobile devices even). And we're moving towards this long run vision. Step by step we believe we can achieve this huge goal. And eventually, reinvent quality control for every possible digital product. 🙂

@geek_1001 Showed this to our designer and he made a good point. What is the value of a tool like this when apps like Sympli and Zeplin give you the exact dimensions, coordinates, and styles of everything?

@patrickleeadams @geek_1001 thanks for showing it to your designer! We love an honest feedback, like yours!

@patrickleeadams Hello, Patrick! Thanks for showing it to your designer! And I'm very glad you've asked this question 😊 Let me start with questions from my side: if we have tools like Zeplin or Sympli why do we still have UI snapshot testing in iOS? 🙂 From the overall vision perspective: 1. We are aimed to solve the visual quality problem (in the long-run strategy bunch of others quality factors in digital products). 2. Zeplin and Sympli are collaboration tools for designers and developer – they are doing everything for everyone. We're focused on a single problem – visual quality control. Because of this focus, we have much more opportunity to actually solve the problem. 3. We're moving step by step so there are more to come from our side regarding visual quality control (automation, issues highlight and so on) From the product perspective: 1. We're integrated inside iOS simulator – this gives us more flexibility in feature specifically for iOS developers. 2. Since we're in the simulator you don't have to change your context every time to check your implementation. (you can just use hotkeys instead of opening third-party window, place this comparison in the right spot and so on) And at the end – we are humans after all. Even if we have all the data, guidelines, specifications and so on – the end product could be different from your expectation. The fact that you have the guidelines doesn't guarantee the result. And that's the problem with tools like Zeplin or Sympli, they cars about the process, to provide all the guidelines, but they don't care about the actual result of this guidelines. On the other hand, we care about the end result and do not provide any guidelines for the process. I'd say we (Flawless App and collaboration tools for designers and developers) complement each other. So there will be some integrations for sure 😊 Does it make sense?

@geek_1001 Sympli is a part of our workflow - it provides styles and assets so if I am using it for that, then I may as well use it for the dimensions/coordinates it provides as well. Most developers have two screens, so context switching between Sympli and the Simulator is not an issue (for me at least). When I implement UI I check the dimensions in Sympli against the dimensions in Interface Builder. For something like Flawless you have to run the project each time you make a change. So for someone who wants to just put a UIView in the correct location and be done with it, they can't, they have to keep moving it and running the simulator. For larger projects this would be a hassle. I also believe that there is more precision when comparing actual dimension values than there is with overlaying. With that being said I do think Flawless is good for double-checking things at the end but I don't think it makes sense to use it from the beginning. All-in-all I am looking forward to see what you guys do in future updates.

@patrickleeadams Got your point. Totally make sense. I think because we're moving step by step since we're still a small team, we can't do everything that's on our mind at the current moment in time. We decided to move with short but extremely fast product iterations to get relevant feedback as fast as possible and improve the product based on that. So thank you so much for your feedback! 😊

@adiatlov Thank you Alexander!

@adiatlov Alex, thank for your question! 🙂 We decided to put 14 days trial based on numerous user research and interviews with our early beta testers and engineers from different countries and companies. We find out the average period for UI tasks varies in different companies like: - For Product companies (big and small ones) = ~7 days - For Outsource companies (big and small ones as well) = ~13 days - Freelance Individuals = ~4 days Surely this period depends on the product/project, country and engineer's level. But we decided to put 14 days as an approximate period for all types users.

@adiatlov as for me, 14 days trial looks fine :) bur we are open to consider other options!

@mezanul Thank you so much for your support! 😊 Feel free to share any feedback and thoughts you have. I'd really appreciate it.

@pecherskyy Thank you for your support, Max! 🙂

@pecherskyy Thank you Max :)

@alexdeardream Thank you so much for all your support during this time it was a long journey to public version 🙂

@alexdeardream so cool, that you stayed with us for so long!

@nsmyself thank you for supporting us 😍 😍 😍

@tasteofdalife Thank you, Dmytro! 😊

@tasteofdalife 💗 💗 💗

@andreyazimov Andrey, thanks for supporting us 😻 😻 😻