@luisobo I just read that earlier today! :) So, just to run through the list here quickly (and I'm shortening it down to the essential points for brevity): - iOS AutoLayout capability. So, this is actually one of the core concepts in Fuse. As you say, going from a static design to something that needs to scale, move and adapt is one of the must frustrating problems in modern app design because it touches on so many different points. Understanding that no content element is truly static needs to be "baked in" from the very beginning. This is why layout, motion and responsive elements/animation should be building blocks in app design just like basic primitives like rectangles and circles. But that needs to start from the very first pixel (or indeed, point :), and this is why the _connection_ between a design and/or prototype and the live app equivalent needs to be established really early in the process.. and that's part of what Fuse is for. - Scripts/navigation/logic - the end goal being code generation. I agree completely. With the open beta launch today we're including experimental support for code generation from Sketch documents. Yes, it is still early, but it shows great promise. We are also experimenting with Photoshop, but it is not quite as easy, given the nature of the software. But yes: a design and/or prototyping tool that cannot generate actual code feels weird to us. Why not just skip over the step where a developer has to physically observe something happening and then apply their interpretation of that motion or interaction in code? We think that should change. - The overarching goal for me is that we stop calling this "prototypes" and we start calling them apps. I can't begin to tell you just how much I agree with this. :) I would love it if you took the current beta of Fuse for a spin and tell me what you think. Are we heading in the right direction? What do you think we should focus on? What works, what doesn't work? Feel free to hit me up directly! - GraphQL. Declarative UIs and reactive data-binding is the future of app development -- at least that's how we see it :) You get to do more, with way less code, and when native code is generated at the end anyway, there is no performance loss either. Wow, that got really ranty, sorry for the huge post :)

@gloom303 thanks for replying. Glad to help! Some more feedback: I can see the value in providing your js framework and markup in order to get started quickly, but any serious project should have total control over which frameworks to target. This may be the early day of real code generation of UIs and while we programmers don't look at the assembly code generated by a compiler I'm sure early compiler users did until they could trust the compiler implementations. Point being, users should be able to understand and control the generated code, at least for now. What a product like this should excel imo is at modeling the UI and interactions in a declarative yet flexible way and at having a programmatic API to navigate this declared UI, that's where I think the meat of a product like this is. Then, you can generate whatever you want out of that. Some people may be okay with your homegrown js framework for prototypes and what not or developing with the live reload, some other people may want to use react native because of the larger community or whathaveyou, some others may want to target plain UIKit, some others may want code generated against with this or that library or even integrate some new parts of the app implemented with this tool with a legacy app. There is gonna be, inevitably, a period (I'd say years) in which programmers will want to look under the hood to gain this trust and you, fuse, are gonna want that in order to get feedback from devs to tweak the UI model to make it more powerful. During this few years, people will figure out the things that work and the things that don't and eventually gather around one target (I guess something that is maintained independently like UIKit or react-native) they can trust (the implementation, the performance and most importantly, that the abstractly is solid) and then an only then, we will stop looking under the hood.

@luisobo Thanks a lot for your input - and we totally agree :) In it's current version, and from our current messaging, Fuse may look a little "sandbox-like". But rest assured, it is carefully designed not to be that going forward. Here's how: * In any Fuse project, you can already write Uno (native C#) code which gives full programmatic access to the UI tree, as well as full access to all iOS and Android frameworks. You can mix JS, Uno and UX markup as you want in a project. * We are working on an API for programmatically accessing the UI tree from JS too, but we want to design it carefully so this can never impair UI performance like most other JS-UI frameworks do. That's why it was not released from the get-go. * In a few months, Fuse will support being used as a library in existing iOS (Xcode) and Android Studio projects. This means you can use Fuse (with live preview) to design screens, components or complete UIs on top of existing native code bases. * You can already (and we will expand on this functionality going forward) mix native Obj-C, Swift or Java code in your Fuse projects. Thanks again for your input :)

@bradenhamm You don't actually need Sublime, it's just that that's the first IDE/code editor we built a plugin for. Code completion/hinting and easy preview and suchlike is pretty important for a good developer experience so we picked one editor to focus on first, which happened to be Sublime. I can't promise specific dates, but we're testing integrations with Atom, Visual Studio Code and others as well. But, as mentioned: you can even code in textedit.exe if you'd like -- you just have to live without a few of the convenience functions our plugin gives you. Oh, and Fuse works fine with the trial version of Sublime if you just want to give it a try! Update: there are actually two work-in-progress community plugins as well that you might try/contribute to, one for Atom (https://github.com/ibare/languag...) and one for Visual Studio Code (https://github.com/realignist/vs...)! Update: we now provide our own Atom plugin: https://atom.io/packages/fuse

@vectormein There are several ways. Everything relater to native UI is done through UX markup. Many native features are already exposed as easy to use JS functions in FuseJS, and we are working full speed to add more. Fuse also offers direct bindings to all iOS and Android native APIs.

@sungmoon Thanks for your kind words! We're so happy to have had closed beta users such as yourself who have contributed so much in terms of helping us finding bugs and deciding what to focus on in the designer-developer experience.

@paultomkinson The Fuse beta is free and price plans are still undecided indeed, but here's what we're planning: always keep a free tier that's non-crippled. We strongly believe that Fuse should be software that people can depend on. We are building features on top, and some of these will be combined into a pro version on a subscription model. I'd be very happy to hear your thoughts on pricing though!

@zbijelic Sorry about the size requirements on OS X right now. You're right about MONO, which is currently required for the Fuse runtimes (but obviously not for the things you produce _with_ Fuse :). We're actually actively looking into how we can come up with a better solution on OS X, but in our current open beta state it made sense for us to stick with it in order to save time in getting more people to try out Fuse and let us know what they think. I hope you'll give Fuse another shot at some point! :)

@gloom303 hey Bent thanks for your reply. I spoke with someone via twitter and got it squared away. I mentioned a partial drag / drop module would be fantastic (I am not a developer myself). Unfortunately the product isn't for me, but I am sure that many people will find it useful. Good luck on all future developments!

@zbijelic Thanks! We're still only in beta and have tons of plans! We definitely lean towards developers in the current state, but rest assured: our mission is to unite designers and developers more and more as we grow and evolve. :)

@tony_xiao Fuse isn't related to React Native in any way. We actually wrote a long blog post about the differences between Fuse and RN (and Native Script, for good measure): https://medium.com/@fusetools/ho...

@mr60fps is there any apps in stores already?

@visualwatermark hi! There are a few, but most of them are in private Beta still. Fuse was just made available to the public today 😄 in our forums you can find a few app store apps made and shared by early adopters og Fuse

@visualwatermark @mr60fps My personal favourite so far is https://itunes.apple.com/gb/app/... but we know of a lot of apps currently in development.

@mr60fps OMG man... that "make it pop" sequence was on point! But seriously now, really excited to try out Fuse.

@visualwatermark https://github.com/vinkla/awesom...