Show newer

[] AngeloStavrow opened writefreely-swiftui-multiplatform #51: Add support link to settings screen in iOS target github.com/writeas/writefreely

[] AngeloStavrow opened writefreely-swiftui-multiplatform #50: Set new local post as selectedPost in WriteFreelyModel github.com/writeas/writefreely

[] Closed writefreely-swiftui-multiplatform #17: Set the a Collection for a Post based on selectedCollection w/ Drafts fallback github.com/writeas/writefreely

[] Closed writefreely-swiftui-multiplatform #23: [iOS] Close button does not dismiss Settings sheet after logging in github.com/writeas/writefreely

[] Closed writefreely-swiftui-multiplatform #48: Move sheet modifier for SettingsView outside of NavigationView github.com/writeas/writefreely

[] AngeloStavrow opened writefreely-swiftui-multiplatform #48: Move sheet modifier for SettingsView outside of NavigationView github.com/writeas/writefreely

So, starting with @submit_as, we built the functionality into the Write.as codebase. There was still plenty of copy-paste involved, but we were able to launch this new product much more quickly.

Now instead of creating separate apps first, we're building them into Write.as first and then separating out functionality over time.

Show thread

This might've been a good theory for building modular applications (as I'm hoping to), but in practice causes a ton of headaches for maintenance and end user experience.

Little problems came up right away:

- How do we share user data across platforms?
- How do we create common UI patterns while keeping distinct branding on each platform?
- How do we reconcile slightly-different uses of those shared libraries across platforms?

Show thread

@snap_as was also the first product we launched separately from @write_as, and it was built on the assumption that an entirely separate codebase would be best.

The idea was that the applications would share common components (github.com/writeas/web-core), but would have separate application codebases and storage.

Show thread

Deployment got harder as their platform shifted beneath us, and one day recently our entire site was replaced by a simple message that said, "We no longer support Go 1.9." That was a fun day!

discuss.write.as/t/snap-as-is-

Show thread

A little background: this is driven by Google Cloud being a very, very bad cloud platform to build on as a small team.

We tried it in 2016 as an experiment, and a series of service deprecations since then have caused us downtime and meant us ultimately offering a stable, but stagnated service.

Show thread
Show older

Write.as Development's choices:

A Bunch Tell

This instance is only for A Bunch Tell projects.