Swift is emeging as the language of the future for native ios apps and thete is momentum building to potentially use this in other frameworks rather than the typical C variations.
Lack of swift support is holding me back from embracing fuse for ios development.
Nowadays code snippets are increasingly written in swift.
Hi Peter,
Of course, Swift foreign code support is in our roadmap. Stay tuned 
Do note that in the mean-time, you can reach Swift through Objective C. It’s not as nice as it would be to go directly, but it should work.
I have read several places about a road map. Is it publically available?
We have an internal roadmap as well as a public one. The public one is out of date and is currently being migrated from our old docs to our new system. I should be available in the not too distant future.
I have seen many replies about not too distance future only to see that there has been no progress 6 months later. It is very frustrating when needing to start a project now and does not inspire much faith in the product. I would seriously advise you to be much more transparent and update the roadmaps you have. And update people on any progress or problems of features they consider high priority. Even better would be 1 roadmap that is publically available rather than an internal & external.
Sorry to hear you’re frustrated. I don’t quite recognize the “no progress 6 months later”-part though, which aspect are you refering to? If you’re talking about Swift specifically, that’s a really big feature with a lot of moving parts so it’s not as if we can give out a launch date for that. It’s also the reality of developing software that’s already in use that priority has to be given to stability and bugfixes on existing features over developing new ones.
As for the transparency: we’ve had our public roadmap for over a year and kept updating it as features have been developed, tested and entered the product.
The reason for keeping an internal and external roadmap is simply that users often request large features that are composed of several, often many smaller features that aren’t necessarily public facing. In order to keep track of all of the features or changes necessary to make the single public roadmap feature possible or available, it is necessary to split it up and keep things separate.
We do feel we’re very transparet in how we develop Fuse, both here on the site and in our thriving Slack community where our developers hang out every day, so again I’m sorry to hear you’re frustrated by that and I’d like to know more about what specifically is causing this frustration so that we can do better in the future.
PS: looks like the feature roadmap is already ported to the new docs system, it just isn’t updated or styled yet.
Hi Bent,
I love your guys work and where fuse is headed - the possiblity of being able to prototype and develope applications significantly faster is awesome! I also think Peter’s tone is a bit harsh.
If you have a few moments, I’d like to share some challenges I’ve run into:
Looking for audio support, I found: https://www.fusetools.com/community/forums/feature_requests/audio_support. It’s marked with “The issue in this thread has been resolved.” A comment from 12 months ago says: “…we have top men working on it right now…”.
Assuming it must be done by now, I looked for how to use it. It wasn’t in the documentation, so searched Google but found nothing.
Searched for a roadmap. Googles results point to the obsolete roadmap. But in this post https://www.fusetools.com/community/forums/feature_requests/fuse_feature_roadmap, the last comment From Jake says “Current roadmap doc is here: https://www.fusetools.com/docs/features”.
BTW, your post above also points to this page - but it returns: “Page not found”.
So, I don’t think audio support exists yet. Yes, you can write native code, but that’s not what was being talked about.
I think you’ll see there’s actually a lot of this. As a small example, if you search for “Stay tuned” in the forums, there’s ~40 posts. The problem is not the “Stay tuned”, it’s that there’s no way to tell what the status is or when it’s been completed.
Google’s top results are often https://www.fusetools.com/learn/fusejs - which start off with "You’re reading deprecated documentation. Presumably alot of this will disappear as the new docs come online, although the property docs seem pretty useless (e.g. https://www.fusetools.com/docs/fuse/controls/textcontrol/color).
The videos are awesome. Top notch! The best! Seriously! But, a number of them now say: “NOTE: As of Fuse 0.20, this video is outdated.”
Obviously there’s more, but I don’t want to pile-on. My goal was to give a taste of some of the challenges a new user is running into “right-now”. Some of it will improve (maybe you should just remove the old “Learn Fuse” stuff?) Others, like the internal feature/bug tracker seems like it will continue to cause problems like the “Stay tuned” example above - since it is invisible to non-employees and can’t be linked to by the forum feature/bug system. Maybe moving at least the language to github as open source would be a solution?
So, although Peter’s tone is harsh, I also have some simpathy given how much effort is required to adopt a new tool. Especially since the tool could disappear tomorrow (it’s currently closed source) and we have no idea what the costs will be (more like Sketch or more like Adobe CS?!?).
Hey! Thanks for the feedback. I’ll start by saying I agree with both you and Peter’s feedback that seeing “coming soon” on specific features and then not getting updates on that is not good, and I completely understand why it’s frustrating.
Let me answer a few things in particular too…
1) https://www.fusetools.com/docs/features was temporarily down as part of the restyling and updating, sorry about that, but it should work fine now.
2) Getting updates on status/features/progress. Struggling with updating people on this is exactly why we’ve spent a great deal of time working on our forum, adding features like subscribing to email notifications on new posts, thread marking etc. Unfortunately there’s no good way to completely automate notifications on specific types of content in specific threads though, but being active here and taking care to subscribe to these updates will make it easier to keep track of things. That, and reading changelogs and release notes with new releases of course.
3) Google’s top results. Yeah, we’re still suffering from having to balance the loss of SEO scoring against using redirects. The whole learn-section is deprecated and will soon disappear. We simply had to keep both pages active in parallel while the content moving and updating was taking place.
4) Move to Github/Open Source. We’re working towards making Fuse Open Source. In what form and how it’ll be governed remains to be seen, but yes, rest assured we are on it. These things are also a matter of timing and priorities: we don’t want to just push out the source to some of our components or language or compiler and then just leave it there.
5) Disappearing tomorrow/cost. As with all things software (just look at Facebook’s Parse), nobody can offer guarantees for the future, but I can say we have no intent to disapper tomorrow. As for cost, if you’re using Fuse today, most of what you’re currently using will remain free. We’re not looking to charge for what exists today, but rather to bring value to additional products and services that go along with the core concept of Fuse. I’ll be able to talk more about what that’ll be later this year.
I hope that answers at least some of your questions above
> **Erik Faye-Lund wrote:** > >
Do note that in the mean-time, you can reach Swift through Objective C. It’s not as nice as it would be to go directly, but it should work.
> Could you please explain us how to do that?
Could you please explain us how to do that?
I’m no expert on this, but Apple provides documentation on interoping between ObjectiveC and Swift.
Erik Faye-Lund wrote:
Could you please explain us how to do that?
I’m no expert on this, but Apple provides documentation on interoping between ObjectiveC and Swift.
I got it working to call Swift from Objective-C 
Here is a tutorial: https://github.com/YugoCode/SwiftFuse#swiftfuse
It would be cool if you guys could add the possibility to include Swift files like you can with Objective-C:
"Includes": [
"*",
"Example.swift:SwiftSource:iOS"
]
And then also the ability to set the Bridging Header in the .unoproj. Because I have to this everytime I build or make a new preview 
Hey Mitnick,
That’s a good idea, and should be low-hanging fruit until we’ve implemented Foreign Swift proper. I’ve created an internal issue on this.
Cheers!
Olle Fredriksson wrote:
Hey Mitnick,
That’s a good idea, and should be low-hanging fruit until we’ve implemented Foreign Swift proper. I’ve created an internal issue on this.
Cheers!
That sounds great!!
Can we expect it for 0.26?
Hey again Mitnick,
I’m glad you’re enthusiastic about it!
I have a number of things on my list before I can start looking at this, but rest assured that it is actually on the list. I can’t make any promises about dates, but will keep this thread posted about it when there’s been progress.
Okay, thank you very much Olle :))
You can actually use
"Includes": [
"*",
"Example.swift:CSource:iOS"
]
and that will work.
I got a proof of concept working with only minor modifications that have to be done to the generated xcode project.
Also you don’t need to add a bridging header if you intend to only call Swift from Objective-C code. You just need that for the other way around
That sounds great Sean, thanks!
What are the “minor modifications that have to be done to the generated Xcode project”?
Support for this has now been implemented internally, and will be included in a future version of Fuse. Keep an eye out for coming changelogs!