There were sure a lot of questions. Wow. Thanks. I'm humbled.
I tried to answer everything as straightforward as possible.
I've grouped things by topic so I wasn't repeating myself too much.
And where possible I tried to give a longer answer to the unasked "why" questions.
I did bow out of 4 things:
OK. Let's do this thing!
Yes. There are some limitations. They primarily come from Styled Text as that's a proprietary feature of RW -- and one that is a bit old and janky IMHO.
To make importing as smooth as possible, I recommend moving away from Text stacks and towards Markdown stacks. Markdown will import seamlessly.
As we get closer to release I'll have more to say about importing content.
I'm shooting for 100% compatibility for all stacks. It's awfully difficult, but that's definitely my goal. However there are probably a few stacks out there that rely on proprietary RW features -- I don't know of any per se -- but it's definitely something that's possible. However, I think it's safe to say that about 99% of stacks will work as is without any updates from developers.
Short answer: No subscriptions!
Long answer: I'm just not a fan. I don't have a good reason. I just don't like it. I feel like I have too many myself. I don't think I can force subscriptions on other people in good conscience.
So what am I going to do? I'm not going to change a damn thing: So…
You buy it, you own it.
One time purchase.
You own it forever.
No surprises.
No gimmicks.
Same as the Stacks Plug-In.
Same as it ever was. Same as it ever was.
But…
I've also been convinced (by someone very patient with me) that there is a place for subscriptions in this universe. The advantage: they allow people to get in the door at a much lower initial price point.
This can be particularly helpful for new users coming to the platform that don't want to risk spending a lot up front -- but want to give the app a solid test-drive.
New users are good. And more options are good.
So I'm not against offering some type of subscription AS AN OPTION.
So long as there is always a one-time purchase option too.
Short answer: I can't make promises, but as of today: macOS 11.
Long answer: This is always a fluid decision -- and it's impossible to predict -- most often the decision is totally out of my hands. Mostly this comes down to Apple and what Xcode supports.
I always try to back-port as much as I can as far back as I can -- it's not profitable for me in the short term, but it seems like the right thing to do. And like many acts of kindness, doing the right thing usually has lots of longer-term benefits that are not as easy for an accountant to quantify.
Usually this means supporting everything Xcode allows. But in recent releases Apple has radically narrowed their support for older macOS versions. It's terrible, I complain to everyone I know at apple about this, but at the end of the day, we have to use the Xcode we're given.
New versions of Xcode are required to build and get modern Sequoia (macOS v15) UI and some nice to have features (full screen dynamic sidebars are awesome). But new versions of Xcode only ship with with libraries to build apps back to Big Sur (macOS v11) -- and it's likely they'll narrow that further in June at WWDC.
There are tricks that we developers can play to try to support an even wider range -- but there are no guarantees.
What I can promise: I'll do my everything I can to support older Macs. I promise.
Yes. The built in mini-web server uses the open source Php engine to render pages for preview or for previewing in a browser.
I have not made any info about publishing/deploying/ftp public yet. So… sorry, no comment. Please check back in a bit. I'll have more later.
Stacks will largely be… like Stacks. So I guess it's a bit of both?
Stacks ships with some basic things. And I've seen plenty of people build with only those.
And there are a bunch of free 3rd party Stacks too.
And there are a bunch of stacks available for purchase.
And there are a few nice frameworks too.
Nope. I'm not a fan of clean slates. The PRO is that writing a clean slate app is a lot easier and more fun. The CON of a clean slate is they tend to throw away working solutions to problems you didn't know you had already solved. In other words it trades developer pain for user pain. I'd rather shoulder the burden than make the user do it. I've been writing software 40 years. I didn't always see things this way. This is wisdom learned the hard way.
But, oh boy, it sure would have been A LOT easier and more fun to write, that's for sure. :-)
Why build on the existing codebase? Simply put, my goal is nearly 100% compatibility with the existing Stacks API.
That is not easy. But the basic rendering engine, the Stacks API, and much of the user interface that you're familiar with is the same code that's been working for 17 years. Integrating that older code, with the newer code of a modern Mac app is the hard part.
But if it's not hard, is it even worth doing?
Some things are all new, of course, simply because there is no other way: there is a brand new theme API for example -- it's the majority of the brand new code. And there's lots of new stuff under the hood too: file storage, stacks loading, new UI's like sidebars and a custom tab interface similar to other Pro apps like Xcode.
Because dev's like to share this stuff on social media, I counted up some of the code recently -- in very rough numbers:
So, kind of half old, half new -- some unchanged, and a whole lot of little improvements? I'm not sure what I expected, but standing back, three years in, and looking at it as a whole… seems about right to me.
This is a long answer. I'm not sure I'll do it justice. There is some good news and bad news. But I'm going to be as blunt and honest here as I can be.
But I think it's safe to say that the short answer is: less-screwed than you're imagining.
Some good news:
Some bad news:
I'm shooting for 100% compatibility with all stacks -- but I think realistically it'll be like 99%. I think SEO stacks should continue to work. They usually rely on Php, which Stacks has always supported and will continue to.
Yes, the text editor now has a substantially larger font -- and uses the standard macOS system font San Francisco.
Oh how I wish I could say YES to this. When I began working on this app because of the unfortunate RW situation, I had already been working on a "web app builder" of sorts. It used Node/React/Mongo to build little apps.
Someday I will definitely either build that app or integrate those features into Stacks. But today is not that day I'm afraid.
No. But that's a good idea. I like your thinking!
I would recommend looking at the intro video from last year's Stacks conference. Although some of the underlying details are new, and a lot more that wasn't functional then is function now, much of the app was presented. It gives a pretty good picture.
But please please please do not make me compare Stacks to RW. It's just really best not to poke a sleeping bear. :-)
I don't have any good news for you today. But I sure would love to tackle this. It's definitely a tough nut to crack.
I have modeled a lot of the underlying Stacks app like an Xcode project -- not in terms of code or complexity, but in terms of managing all the content and trying to contextually show the most important info for the user.
Xcode uses localization bundles to localize UI -- I don't think that's the exact right approach here -- but I could see building something similar.
So I'm intrigued by this problem, but after 3 years in development I think I need to focus on essential functionality first.
It's on my to-do list. It's actually not even that hard -- there's just a lot of other things on the list too. I'm not sure if it will make the first release, but I promise it won't be far off.
The sidebar in Stacks has the same controls, but is completely flexible so you can make it really wide and get a lot more characters in there.
And the main edit-area text editor uses a larger font that's easy on older eyes -- especially mine!!!
I'm not really certain I understand this question. I think YES is the answer.
Longer answer: Stacks will continue to function largely as it has -- there is the familiar Edit mode where you can drag and drop stacks and edit text, there is a familiar Preview mode. Previews are connected to a built-in micro web server. And you can preview to a browser too. Changes you make to settings or to the page layout are immediately pushed to the Preview when it's visible.
Yes. I'll continue to build the Stacks plug-in for as long as can. But I don't think I can predict how long RW Classic will continue, so I don't think I can answer the second part with any more certainty than anyone else.
I'm not sure I understand this question exactly.
Instead of trying to guess at the meaning, I'm going to quickly answer a handful of related questions -- hopefully one of these was what you were looking for.
The Stacks plugin will continue to be compatible with RW. I can't predict where RW Classic is headed, but I hope it'll keep going for a long time more.
3rd party stacks built for the Stacks plug-in will always work with the Stacks app
Since the Stacks will have more features and a much more capable API the 3rd party stack built for the app may not work in the plug-in.
RW Themes won't work in Stacks. But converting a theme from RW (or other web development platforms) will be pretty easy. We've built a theme API with the express purpose of making it easy to bring themes from RW or BootStrap or Jekyll or wherever. There is some work involved, but for theme developers it should be a piece of cake.
I probably won't answer the price question until near release.
I don't ever comment on schedules. Ever!!! Except when I slip up and I do. LOL
When I slip up and accidentally do say something schedule related I'm usually guessing and definitely wrong.
Just ask my wife and she'll tell you: Never ask me about schedules. :-)
I'm guessing this upside down sounding question is just a very cute - other language --> english translation confusion. :-) And I totally love it.
But, see above for more details on macOS version requirements.