DEV Community: Yoann Moinet

🧑‍💻 How to remain relevant in this AI era?

Yoann Moinet — Thu, 12 Feb 2026 16:16:36 +0000

With the advent of AI, the software engineering job is evolving, but our responsibilities remain.

Producing code is no longer the hardest or most valuable part of the job.
Solving problems still very much is.

That’s where the real shift is happening.

AI won’t replace problem solvers.
But it will compress demand for pure code writers. It will make pure code writing cheap, and eventually optional.

Which side you’re on will largely determine your near future.
So, how can you lean in the right direction, today?

Be an actor, not a spectator

Watching from the sidelines will make you irrelevant faster than the actual impact of AI on the industry.
Actors drive outcomes; spectators only consume outputs.

This is where careers start to diverge.

If you’re an actor, you’ll compound your value.
Spectator? Anyone else can do it, even AI can do it.
You’re interchangeable and eventually… replaceable.

There are two main ways to be an actor today:

Tame and wield AI effectively
Learn to use it well, in ways that are efficient for you.
Best practices, workflows, skills, commands, prompt engineering, local setup, limitations …
Treat it as a power tool, not a magic box.
Expand your problem-solving surface area
Work on codebases you’re not familiar with.
Use AI as a translation layer across languages, frameworks, and paradigms.
Apply your problem-solving skills, your judgement, your taste and reasoning, to a much wider surface area.

Be intentional and explicit

Never blindly accept AI output.
Review it. Sanitise it. Improve it.
Use your expertise, and yes, use AI again to refine it.

Follow a clear, repeatable process, make it better, and stick to it:

🤖 Plan | 👨‍💻👩‍💻 Chaperone
🤖 Execute | 👨‍💻👩‍💻 Chaperone
🤖 Verify | 👨‍💻👩‍💻 Chaperone

Any step can be done by AI.
None should be fully delegated to AI.

You remain accountable. You supervise. You decide.

Your (new) job: tame the tool

AI is just that. A tool.

Your job is to know how to use it effectively, reliably and safely.
It is nothing more than an extension of your expertise. Not a replacement of it.

People (used to) go to the circus to see lions.
But, at the end of the day, the tamer is the one getting paid.

In the past, staying relevant meant learning new languages, paradigms, frameworks, or platforms.
Today, it also means learning how to work with AI at a high level, because it only amplifies the expertise, taste, and judgement you already have.

For engineers early in their career, this means doubling down on fundamentals.
AI is only useful if you know what “good” looks like. It won’t give you opinions or instincts.
Skipping fundamentals and jumping straight into AI is how you become a fast, confident producer of bad code.
This is how you build experience: study opinionated work, internalise the trade-offs, and develop your own standards.

Do not delegate your responsibility

Delegating responsibility is how you make yourself irrelevant, slowly but surely.

Anyone can ask AI to generate code. My brother, a sushi chef, is doing it.
It can look, and be, production ready. But without judgement, standards, and review, it will progressively turn into unmaintainable slop. (Sorry bro')

Very few can steer it precisely, validate its output, and make it consistently useful.

AI can produce good code, engineers produce systems.

That's where your problem-solving skills matter most:

understand the problem
figure out the right solution
orchestrate its implementation
own the outcome

A good exercise to enforce this is to be able to precisely explain the problem, the solution and implementation.
Unless you really understand them, you won’t be able to explain them to someone else.

Invest in the right things

Experimenting with core models and first-party tooling is great.
Obsessing over every new thin wrapper or orchestrator built on top of them is not.

The pace of change is overwhelming. No one truly keeps up with everything, and that’s fine.
What matters isn’t tracking every new tool, but working from first principles: pick a vanilla LLM, understand its core capabilities and limits, and experiment deliberately.

Remain alert and open.

Do not over-invest in niche wrappers, orchestrators, or other products that merely patch temporary gaps in current agent capabilities.
Many of those gaps will disappear within months, with a simple agent update.

It’s the equivalent of mastering jQuery in the 2010s without understanding JavaScript.

Retain the methodologies and the workflows.
Not the particularities and specificities of the tool you’re using this week.

Invest in learning how to use LLMs in general, how to steer them the best, what standards to apply.Not just which button to click.
Think prompt engineering, skills, AGENTS.md, commands, things that transfer across tools and generations.

My optimistic hot take is, if anything, AI will ultimately raise the overall level of code quality.
It will widen the gap between bad code vs good code.

Given how easy it becomes to build instead of buying, new products will need to be exceptionally good to justify being acquired or paid for.

It raises expectations. It raises the value of engineers who think, reason, and decide.

🧑‍💻 Platform Teams best practices

Yoann Moinet — Wed, 15 Nov 2023 16:39:31 +0000

Bon matin 👋

I'm Yoann Moinet, a Frenchman living in Montpellier.
In early 2019, I joined Datadog and bootstrapped the Frontend Platform team.

But, what is a platform team you ask?

[opinionated vision]
They're here to improve the Developer eXperience and remove any pain points in the day-to-day work of all the engineers.
They can cover a lot of ground: build, tests, deployment, code health, internal tools, and even more...

Let's say, in a company, the engineers are working on a product or a service to satisfy the customers.
The platform team works on the platform to satisfy the engineers, building anything they can think of, to improve the reliability, productivity, efficiency and (more importantly) the happiness of our engineers shipping the product to our customers.
[/opinionated vision]

Working in a large scale environment at Datadog, we had to come up with some kind of charter so we stay focused on what's really important (DX) and don't try to fix everything at once: that would end up being a bad experience for everyone involved.

You have to be laser focused on what you want to achieve and always work incrementally.
There, I gave you the first best practice for free...
jk, they all are for free.

Over the years, I've identified a few best practices (most of them directly translated from our charter) that could be phrased agnostically enough to be applied not only to the frontend, but to any kind of platform team.

1. 🏢 Workflows --not their implementation-- need to be shared company wide.

You should share similar workflows between teams and technologies, so it's easy for newcomers or someone working on an incident to quickly get up to speed even in a different repository/project.

Markers and primitives need to be identified in each workflow in order to keep them similar across implementations.

These implementations can be different as long as a team is there to own the support and follow the same identified markers/primitives.

In the case where there is already an established tool foundation, you should have, at the very least, hooks/flexibility/documentation to customize the workflow in order to align with the project's tech stack and complexity.

🔎 IRL Example

We have a command to deploy to staging from whichever repo you work on.
This command waits for the feature branch's pipeline to be 100% ✅ before triggering a merge and deploy into our shared staging.

For the frontend, in a dedicated repository, it's safe enough to deploy on staging at an earlier step in the pipeline, so we updated the global tool to only wait for a specific job in the CI before deploying. This way it can trigger much sooner for our frontend engineers.

This alone reduced the staging workflow by half for our frontend teams without impacting the global workflow itself, and sharing the same primitives with the rest of the company.

2. 💡 Workflows should not be created or changed unless it's tightly related to a known and documented problem.

You may want to test new technologies, or read articles about new workflows and you want to try them out.

But unless you have a known issue with the related process, you should not change it.

You need to reach a consensus among impacted teams before starting any work on a new workflow or its update.

Exploration is fine though. Necessary even, to understand what the community has to offer.
See next point.

🔎 IRL Example

We use RFCs to have a transparent and open discussion about new technologies we want to use, or new workflows we want to implement.

Having a document written down helps with the global vision of the change we're about to make. It reveals misplaced or incompatible workflows and edge cases.

We're able to gather feedback from everyone involved and refine it along the way. To make it even better and more personalized.

3. 🗺️ Keep exploring what the community has to offer.

Keep a good exploration routine and a thorough tech watch. Using Hacker News, Reddit, X (Twitter), whichever you prefer. There is no single answer as long as you keep yourself up to date with what's happening in the community you're part of.

🔎 More details

When you want to try something new, do it in a controlled, sandboxed environment and process.
Keep a written list of things you're improving, as well as shortcomings and potential maintenance costs along the way.

You don't really have to go all in, it's really just to understand how it would translate to your area and the specific needs your platform has.

Later down the line, you'll notice that you'll be able to connect problems and feedback with solutions you've seen during your watch.

4. 💻 The technology chosen for a workflow should be known and understood by the people that use it the most.

Workflows implemented for the frontend should use JavaScript. For the backend, Python is used, etc…

This allows the people that are the most impacted by the workflow to fix and tweak it if needed.

🔎 IRL Example

We used to have a monorepo for both our frontend and backend.

The infrastructure was orchestrated around a Rakefile (Ruby) triggering Bash and Python scripts. No-one from the frontend teams wanted to dive into that.

We've split the frontend in its own repository, and started to port everything to NodeJS. Making it more approachable for us and the other frontend engineers.

5. 🦾 A workflow should be tightly related to the infrastructure it's applied to, its needs, and its context.

You should not try to implement a workflow once and expect it to cover every problem in existence across unrelated platforms or infrastructures.

A workflow should be implemented in the context of the infrastructure it's running on/over/in…

If you aim too broad, you'll end up with a cluttered workflow that's loaded with unwanted overheads, slower and more complicated than needed. This will impact multiple engineers, everytime they use it.

You implement and test it once, they use it thousands of times everyday.

🔎 IRL Example

Deployments used to be handled by a Bash script, written outside of our repository, which triggered a Go script, also in a different repository.

This workflow and tooling was written to cover every need, for everyone, with many conditions and edge cases.

Like the Rakefile based infrastructure from the previous example, nobody wanted to touch these Bash or Go scripts. It was slow, but too difficult to really update without a risk of breaking deployment of other projects.

We wrote our own deployment script with only what was needed for deploying our frontend. It's in NodeJS, versioned in our main repository, so everyone can tweak it as needed, and be aware of its changes. And it shares the same primitives as the rest of the company, so anyone from outside can still interact with it.

The overall workflow didn't change, meaning that from the engineer's point of view, nothing changed. The process is now 10 times faster and our frontend engineers are able to change what is uploaded or not simply by changing some JS code they are already familiar with.

6. 📣 Any new or updated workflow should be transparently communicated at large.

Too much is better than not enough (in this context).

When you finally have a go at a new workflow or updating an old one, it is very important to communicate at every step of the process to every one impacted by it.

🔎 More details

You start with a presentation of the whole project before the first line of code is even written. You explain why and how you do it, with an overall approximative timeline (can also be done through an RFC).

Then, once you've started working on it, you regularly report progress, clarify the timeline and list any required actions at every step of the migration (if necessary), this can be done by mail.

Finally, at completion, you explain again the new/updated workflow, but also reflect on what went well and what could have been done better, this can be done by mail and presentations.

This helps other engineers see your work. Enforcing the idea that you're not just a support team, but that you care about their happiness and you act on improving it every day of the week.

7. 🏷️ You own the platform, they own its use cases.

When creating a new tool or trying to find a new solution, it's important to think about ownership from the start.

Whatever solution you'll need to implement will end up being used by tens, hundreds, or, if you're very lucky, THOUSANDS of engineers.
You have to think of it as a platform from the beginning, a platform to which anyone could plug their very own tweak to it.
Tweaks that will ultimately be owned by them, meaning that any bug, fix or modification will be handled by them. Meanwhile, you can focus on the platform and the glue that ties everything together.

Ownership of these additions have to be very clearly defined and more importantly enforced. Either by documentation or even better, with a CODEOWNERS file.

In addition to that, contributing to that platform should be clearly documented, and if possible automated as much as possible. If you want people to help you, you have to help them do it in the most frictionless way possible.

🔎 IRL Example

We have a CLI platform in our frontend repository that we use for any tooling need. It goes from printing some information from the CI/CD to uploading our assets in production.

Anyone from anywhere, as long as they know how to write TypeScript, can contribute. All they have to do is run a CLI command to bootstrap their very own command. It will create the files, add them to the CODEOWNERS file and through comments in the code give some good practices and guidelines.

We've grown it to more than a hundred commands, all of them documented, fully owned and easily accessible from our repository.

8. 📋 Gather feedback periodically, if not continuously.

It is very important to keep yourself very aware of what happens in the community you're helping.
You need to understand how the platform is used everyday by your engineers.

There are a few ways to keep yourself in the game.

You can conduct regular embeds, from your platform team into product teams, so you can experience first hand the DX for a given team.
It means you'll work with them directly, as part of their team and following their processes.
You still have to prepare for it, meet with the team's leads beforehand, explain the motivations and look for self-contained tasks that can be completed easily, as if they were done by a new team member.

Another solution is to survey teams.
There are different ways of doing this, the easy way is to have a form with questions.
More complicated ways could be:

Some questions integrated into common CLIs.
Injected forms/popups in common tools' UI.
Automated Slack questions.

Your imagination is the limit.

A few tips for surveys though:

Questions should be the same across iterations, so you can track progress.
Questions should follow some kind of "framework" both for the phrasing and the meaning (like SPACE).
Remain high level, you'll go deeper later on if you need to.
Keep the survey as short as possible.
Organize the questions by theme.

When it's time to end the survey, analyze the answers and identify patterns.
Don't focus on the "one-off" comments, see the big picture.

🔎 IRL Example

We send a survey to all the frontend engineers twice a year.

It's usually sent out a few weeks before the transition to the next quarter, so we can use the results to define our objectives for the next 6 months (it spreads over two quarters).

We also brought in other platform teams so they can ask their own questions as well, so we keep a single survey, instead of having plenty of them and tiring our engineers with questions all year round.

It really helped our team, drove it in the right direction, especially when I was alone in it, to better define what was the most problematic and which points were high value for a small cost.

I hope this clears things up for you and will help you better manage the platform work at your company.

Do you have best practices regarding platform teams you'd like to share?

Psssst... 🤫 we're hiring.

ℹ️ This is a re-work of my previous article Developer Experience Magna Carta with more content.
🌄 Photo by Max Duzij on Unsplash
Thank you Erik for the thorough proofreading.

Developer Experience Magna Carta 📋

Yoann Moinet — Tue, 16 Feb 2021 15:32:13 +0000

ℹ️ I've reworked this article in a different format with more content.

🧑‍💻 Platform Teams best practices

Yoann Moinet ・ Nov 15 '23

#dx #programming #devops #devrel

Bon matin 👋

I'm Yoann Moinet, a frenchman living in Montpellier.
In 2019, I joined Datadog and bootstrapped the Frontend Platform team.

But, what is the Frontend Platform you ask?

We're improving the developer experience and remove any pain points in the day-to-day work of all the Frontend engineers at Datadog.
We cover a lot of ground: build, tests, deployment, code health, internal tools, and more...

Working in a large scale environment, we had to come up with a charter so we don't lose focus and try to fix everything at once: that would end up being a bad experience for everyone involved.

Here is our charter:

1. 🏢 Workflows --not their implementation-- need to be shared company wide.

We should share similar workflows between teams and technologies, so it's easy for newcomers or someone working on an incident to quickly get up to speed even in a different repository/project.

Markers and primitives need to be identified in each workflow in order to keep them similar across implementations.

These implementations can be different as long as a team is there to own the support and follow the same identified markers/primitives.

In the case where there is already an established tool foundation, we should have, at the very least, hooks/flexibility to customize the workflow in order to align with the project's tech stack and complexity.

🔎 Example

We have a command to deploy to staging from whichever repo you work on.
This command waits for the feature branch's pipeline to be 100% ✅ before triggering the deploy.

For the Frontend, it's safe enough to deploy on staging at an earlier step in the pipeline, so we updated the global tool to only wait for a specific job in the CI before deploying. This way it can trigger much sooner for our Frontend.

This alone reduced the staging workflow by half for our Frontend teams without impacting the global workflow itself.

2. 💡 Workflows should not be created or changed unless it's tightly related to a known and documented problem.

We may want to test new technologies or read articles about new workflows and we want to try them out.

But unless we have a known issue with the related process, we should not change it.

We need to reach a consensus among impacted teams before starting any work on a new workflow or its update.

🔎 Example

We use RFCs to have a transparent and open discussion about new technologies we want to use, or new workflows we want to implement.

Having a document written down helps with the global vision of the change we're about to make. It reveals misplaced or incompatible workflows and edge cases.

We're able to gather feedback from everyone involved or touched by it and refine it along the way. To make it even better and more personalised.

3. 💻 The technology chosen for a workflow should be known and understood by the people that use it the most.

Workflows implemented for the Frontend should use JavaScript. For the Backend, Python is used, etc…

This allows the people that are the most impacted by the workflow to fix and tweak it if needed.

🔎 Example

We used to have a monorepo for both our Frontend and Backend.

The infrastructure was orchestrated around a Rakefile (Ruby) triggering Bash and Python scripts. No-one from the Frontend teams wanted to dive into that.

We've split the repository, and started to port everything to JS. Making it more approachable for us and the other Frontend engineers.

We've created a new deployment platform for internal applications, written in JS. It is now used by more than 5 different teams, with 10 new internal applications, all of them maintained solely by Frontend engineers.

4. 🦾 A workflow should be tightly related to the infrastructure it's applied to, its needs, and its context.

We should not try to implement a workflow once and expect it to cover every problem in existence across unrelated platforms.

A workflow should be implemented in the context of the infrastructure it's running on/over/in…

If we aim too broad, we may end up with a cluttered workflow that's loaded with unwanted overheads, slower and more complicated than needed. This can impact multiple engineers, everytime they use it.

We implement and test it once, they use it a thousand times.

🔎 Example

Deployments used to be handled by a Bash script, written outside of our repository, which triggered a Go script, also in another repository.

This workflow and tooling was written to cover every needs, for everyone, with many conditions and edge cases.

Like the Rakefile based infrastructure from the previous example, nobody wanted to touch these bash or go scripts. It was slow, but too difficult to really update without a risk of breaking deployment of other projects.

We wrote our own deployment script with only what was needed for deploying our Frontend. It's in JS, hosted in our main repository, so everyone can tweak it as needed.

The overall workflow didn't change, meaning that from the engineer's point of view, nothing changed. Just the process is now 10x faster and our Frontend engineers are able to change what is uploaded or not simply by changing JS code they are already familiar with.

5. 📣 Any new or updated workflow should be communicated at large.

Too much is better than not enough.

When we finally have a go at a new or an old workflow, it is very important to communicate at every step of the process to every one impacted by it.

We start with a presentation of the whole project before the first line of code is written. We explain why and how we do it, with an overall timeline (can be done through an RFC).

Then once we've started working on it, we show progress, give a clear timeline and any required actions at every step of the migration (this can be done by mail).

Finally, at completion, we explain again the new/updated workflow, but also reflecting on what went well and what could have been done better (this can be done by mail and presentations).

This helps other engineers see our work. Enforcing the idea that we're not just a support team, but that we care about their happiness and we act on improving it every day of the week.

I hope this clears things up for you and will help you manage the DX at your company.

Do you have best practices regarding the DX you'd like to share?

Psssst... 🤫 we're hiring.

🌄 Photo by Brooke Cagle on Unsplash
Thank you Erik for the thorough proofreading.

Electron on the App Store, Post release.

Yoann Moinet — Tue, 09 Feb 2021 21:41:19 +0000

This article is part of a 5 articles series about the publication of an Electron application into the Mac AppStore, Fenêtre.

Fenêtre, fənɛtʁ, lets you better multitask on your mac. It enables a picture-in-picture mode for any website/web-app, image, video or flat file.
You can find the free versionand the paid version on the Mac App-Store.

Of course your app is perfect and has no bugs. But people need to be reassured, they need to be able to contact you, to congratulate you on your awesome work, on how you're a wonderful human being, and sometimes, tell you stuff about your mom.

Contact & feedback

Having a line of communication with your customers is vital, a minimal setup involve having a very basic email redirection with your domain registrar. Having a Twitter account for the app helped a lot as well and I'm currently testing a Facebook page, we'll see where it goes.

People tends to send valuable feedback, giving their take on the app and what would make their experience even better. It often opens up to great new ideas. When someone takes the time to give you feedback, it's constructive, most of the time. That's how I got to implement the setting to show/hide the dock icon, the size of the see-through mask, the context-menu, and more. Many, many, many bugs, that I never encountered before, were now reproducible with steps, and more importantly, fixed.

But, we're not snowflakes ❄️, negative feedback is inevitable, just don't take it too personally, people don't even know you anyway. A part of the negative comments I got felt like jealousy more than anything else. It was always in the form of "Meh, I wouldn't have done it this way... it's useless anyway...", your level of vulgarity may vary of course.

The other part was actually very constructive and helped me improve the app.

Anyway, I just know for a fact that I am a wonderful person, and so are you 🌷

A Bug's life

It's never fun as a user to get an unexpected error pop up in your face. So the first thing to do in my opinion, when you're packaging your app is to deactivate them.

For this I've used the awesome electron-unhandled which will intercept every exceptions of your app, both on the main process and the renderer process.

Block error popups in production.

It's really easy to setup, and you'll be able to handle all your errors in one place. Note the use of our IS_PRODUCTION global variable set in Webpack earlier, to completely remove any dialog related to errors.

The only thing that you need to do is execute this as early as you can in both processes, main and renderer. I usually put it at the start of my app.js and in the <head> of my views.

You still need to get a ping when that happen, don't you think? For this, you can easily setup a free account on Mailgun which will let you send up to 10000 emails per month. If you ever need more than that for your app, it means that you're more than able to pay for it.

Thanks to mailgun-js and a very thorough tutorial written by Mailgun you'll be up and running in no time. Then, you can do something like that in your unhandled configuration:

Send me an email instead of showing the error to the user.

Conclusion

This whole experience was very enlightening and taught me so much on every aspects of the application's ecosystem and life cycle on Mac OS X. From the very beginning of the conceptualization to the publishing into the AppStore, even after that, marketing and doing support. It was a blast, and still is, I'm very glad I was able to stay motivated all along.

And it didn't even cost me that much (±130$) for a 10x return on investment after the first month. For which I'm very grateful, I never expected that.

There were very hard times, but the most painful it became, the more enjoyable the finality was.

I'd do it again anytime, and I'd still choose Electron for this job. But for a different app, less tied to a web-view, I'd definitely go with Swift, I'm not that crazy.

Hope you enjoyed my writing, I don't do that often. But if this is well received, I might write some other stuffs.

Electron on the App Store, Go to market.

Yoann Moinet — Tue, 09 Feb 2021 21:41:06 +0000

This article is part of a 5 articles series about the publication of an Electron application into the Mac AppStore, Fenêtre.

Fenêtre, fənɛtʁ, lets you better multitask on your mac. It enables a picture-in-picture mode for any website/web-app, image, video or flat file.
You can find the free versionand the paid version on the Mac App-Store.

This is where you have to excel if you really want to sell your app. There is no "organic marketing/sharing/growing", at least not initially. You have to go out there, pull your fingers from your ass 👉 🍑 (french saying, don't bother) and make your app look pretty and useful.

Make a video... or many

You've been working on your app for half a year now. Of course it's filling a need, it's obvious... to you... and only you.

People don't know they need it so badly. Sometimes, they don't even understand what it does.

A great way to fix this is to make short videos, showing how it works.

Here's what I did myself, I'm no video maker guru ninja, but at least it's showing some of the features at a glance and breaks the ice of the first use.

Another way is to share real-life usage. People need to see themselves using your app.

Multiple points of entry

You have to share your amazing creation and create as many entry points as possible. For it, you'll have to submit it to a big number of platforms. And more importantly, always share promo codes, you have 100 of them for each version of your app, so don't be cheap with them.

The way I see it, there are three types of channels:

Ephemeral

This is where a lot of content is shared everyday, and it's organically and automatically curated by a great number of users. Big amount of content, big audience, very fast content rotation and very small attention span.

When sharing there, you'll have to be straight to the point with very explicit visuals. Show what it does and how it does it, limit your post to only the greatest/fanciest characteristics.

Be careful to sync your post with the timezone of your principal target as well, otherwise it will be drowned very quickly.

Here are many great tips for posting on Product Hunt.

Example of ephemeral platforms: HackerNews, ProductHunt, specific subreddits like /r/apple, /r/macapps, /r/appdev, /r/app, /r/startups, /r/entrepreneur, /r/sideproject...

Temporary

Another less fast paced platform would be blog posts and videos. Small amount of content and big audience. There is a rotation of content but way slower than ephemeral platforms.

You have three possibilities here. Either your app gets published naturally when a blogger finds it via another channel. Or you'll send it yourself to as many tech blog as you can and get lucky. Or you'll write the article yourself, or five of them 😘.

Durable

For a highly specialized content but small audience (at first), no rotation of content and great attention span, you have your own app's website/blog, advertising, as long as you pay for it, or partnerships with other services/products.

Show them what they're missing out

Free users have a limited set of features, but still get to see the settings window. It is a great opportunity to show them what they could get once they decide to upgrade.

Here's the settings of the pro version, you can change default behaviors and set your own hotkeys.

So here's what I first tried, a very light, subtle hint about the pro features:

Needless to say, this got rejected by Apple faster than I was rejected in high school. But Apple did let me have this instead:

So, don't be too obvious. Subtlety seems to work the best (should have known that in high school).

Everything is now in place to sell this app, but what about its after-life? What can we do Post release?

Electron on the App Store, Ship it.

Yoann Moinet — Tue, 09 Feb 2021 21:40:51 +0000

This article is part of a 5 articles series about the publication of an Electron application into the Mac AppStore, Fenêtre.

Fenêtre, fənɛtʁ, lets you better multitask on your mac. It enables a picture-in-picture mode for any website/web-app, image, video or flat file.
You can find the free versionand the paid version on the Mac App-Store.

This is the last mile, and also where I almost lost it. By far the most painful part of the whole project.

Working with Electron, you won't publish, sign or handle entitlements from XCode, and Apple seems to make it even harder for you since you're not using their proprietary software. The documentation is cryptic, to say the least, and the support is yet to be found.

What helped me a lot was the WebTorrent for desktop repo, especially their packaging script, so, a very big thank you to the team there ❤️, your project saved my sanity, for real 🙏.

Following their great example I've been successfully using electron-packager and electron-osx-sign which are must-have packages to ship your product to the AppStore without XCode.

Certificates & stuffs

First of all, you'll need 3 different certificates from your developer account.

Mac development, so you can test your signed packaged app before sending it to Apple.
Mac AppStore → Mac App Distribution, so you can sign your app and all executable inside it.
Mac AppStore → Mac Installer Distribution, so you can sign the package of your app, which is the format you'll send to the AppStore.

Simply download them, double-click and they will be installed in your keychain. That's it, you won't have to deal with these anymore until they expire.

Then you'll need to create an App ID for your app (one for each version, free and pro), and finally, two provisioning profiles each, one for development and one for distribution.

Now you're ready to sign your app.

Entitlements.plist

Using plist.js you can create your two entitlement files needed, parent.plist and child.plist. I like doing it in the packaging script, so I don't end up with multiple files I'll never edit.

The parent will need com.apple.security.sand-box at true, because your app _has_to be sand-boxed before being submitted to the AppStore. And com.apple.application-identifier and com.apple.developer.team-identifier to identify your app.

Add any other needed entitlements depending on what your application does.

As an example, for Fenêtre I'm also using:

com.apple.security.network.client since we're connecting to the internet when displaying a website or any URL in Fenêtre.
com.apple.security.network.server for the browser extension, so it can send URLs to open. It's also used when encoding/decoding unsupported video formats.
com.apple.security.files.user-selected.read-write for the user to drag-n drop files into the app.

In the child.plist it's quite easier, you just need com.apple.security.sand-box and com.apple.security.inherit at true. That's it, that's all, output those file somewhere temporary, we'll use them later during the signature process.

Signature

Now to the big tricky part, the signing of the app. Fortunately for us electron-osx-sign has done most of the hard part. Here's a snippet of my production signature script:

Signature script for production.

The only two arguments needed, appPath and pkgPath , are the .app's absolute path we've created with electron-packager and the absolute path of where we're outputting the .pkg.

Note the PARENT_PLIST_PATH and CHILD_PLIST_PATH that we also created earlier. And the two different identities we're using, one for the application itself, and another one for the .pkg we're generating. And the platform is mas for 'Mac AppStore'.

Now this package won't be testable on your machine, not even the signed app. Instead, you'll have to use another sign script for being able to test your sand-boxed application:

Signature script for development.

Note that we don't need the generation of the .pkg anymore, since we won't test it. Also, the type changes to development, and the identity is now the Mac Developer one. As well as the DEV_PROVISIONING_PROFILE.

Debug your sandboxed Application

You now have the exact same app as the one that will be shipped to Apple. So you can test the sand-boxing, which is very important and very likely to crash.

Be sure that everything works in this state, or it will be rejected by Apple right away. You can use the very useful RB App Checker Lite as well, to test the entitlements and the signature of your app.

There's still this ' The profile does NOT match the application's Team ID' I can't get rid of. But apparently, this is not a big deal ¯\(ツ)/¯.

If you need to see the output of your main process, get into the package contents of your generated .app and open the file located at MyApp.app/Contents/MacOS/MyApp, it will open a terminal window with the output of your main process.

To inspect the renderer process, simply spawn the web inspector from your BrowserWindow's options with the help of our global IS_PRODUCTION:

Now that you're all set, you can use the Application Loader to upload your Application.pkg to your iTunes Connect account.

It's hidden in XCode > Open Developer Tool > Application Loader. Just open it once, and pin it to your dock, so you don't have to launch XCode each time you need to upload your app, which will happen a lot.

Then from iTunes Connect you'll be able to select your latest build for the next release.

Wait for the review to happen... update your app, and back to the start, until it's validated and pushed to the AppStore.

Now that we have our package uploaded and published, we're ready to Go to market.

Electron on the App Store, Pain & tears.

Yoann Moinet — Tue, 09 Feb 2021 21:40:41 +0000

This article is part of a 5 articles series about the publication of an Electron application into the Mac AppStore, Fenêtre.

Fenêtre, fənɛtʁ, lets you better multitask on your mac. It enables a picture-in-picture mode for any website/web-app, image, video or flat file.
You can find the free versionand the paid version on the Mac App-Store.

Development usually comes with some pain, this is not new, but I'll try to cover what was particularly hard to fix and/or to find a solution for.

Custom schemes

I wanted to use the custom scheme fenetre://to open links from the browser into the app. It seemed so easy following Electron's and Apple's documentation on the subject. And it worked flawlessly in development.

Once sand-boxed, it stopped working. And it wasn't an easy found bug, since it took 3 fully published and reviewed versions to figure this one out.

You could accurately follow my descent into the abyss through the @FenetreApp twitter feed.

// Detect dark theme var iframe = document.getElementById('tweet-917662600401506305-519'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=917662600401506305&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-917883630243983361-981'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=917883630243983361&theme=dark" }

But, eventually... in the end.

// Detect dark theme var iframe = document.getElementById('tweet-918254037467910144-800'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=918254037467910144&theme=dark" }

Instead of using a custom scheme, I had to run a server in the app, on a specified port. Then, the browser extension would call a route on this server to open the URL, passed as argument, into the app 🤮.

And I hate this so much.

DRM Content

EDIT: This is now impossible to mock. You'll have to use a proprietary tool to publish your app in order to hope serving DRM content.

When delivering content from the web, especially videos, you'll be hit in the face with DRM. Netflix, for example, won't let you play videos anywhere you like. You need a decoding plugin, called Widevine. It's already embedded in your day-to-day browser, but when you're using Chromium (Electron's core) you'll need to get it yourself.

The best way is to look for the Chromium's major version your current Electron uses via process.versions in the renderer process. Then download the same version of Chrome and go spelunking into the .app file.

At the time of this writing, it can be found here:

Google Chrome.app/Contents/Versions/[version]/Google Chrome Framework.framework/Versions/A/Libraries/WidevineCdm/

Finally, activate it in your app, as early as you can, before app.on('ready'):

You can do the same with the PepperFlash plugin, to read flash content.

Important notes:

to be updated alongside Electron.
to be manually copied into your package.
to be referenced as an absolute path.

The French tartine de caca

Since I'm French, I wanted something that sounded French. That's where this ê came in, busting everything I did.

Fenêtre was a fun name, pronounced fənɛtʁ or Fonaytre, it means window in French, so it was very relevant to the project and it sounded putain de French. But nothing prepared me to how painful it would be to use a non-ASCII character in today's internet. I already knew it was stupid, but not that stupid.

APFS vs HFS+

Some time during the development, I decided to upgrade my machine to High Sierra, what a mistake that was.

The file system changed from HFS+ to APFS, and now, the system doesn't normalize filenames like it used to. So if you have non-ASCII characters in your filenames, you might be fucked. I could not sign my app with codesign through electron-osx-sign for a few days before finding a solution.

The solution I've found, with the help of Zhuo Lu, was to get the name from the Finder and copy the special character from there to use it where needed in the code. Simply because I'm not that well versed in normalization matters, it was an easy enough way of fixing this annoyance once and for all.

Domain Name

Internationalized domain name are around for some time now. You'd think it should be well supported all around the internet... BOOM, wake up, it's not.

First, in most forms where you have to enter a domain name, you won't be able to use the special form fenêt.re, it will be rejected by the validation, instead you'll have to use the xn--fent-ipa.re form. So, developers, please update your validations so I can submit my website in its best form.

Second, now that it passes the form validation, it will be displayed either badly, without the special char like fent.re, or simply will be swapped back to the xn--fent-ipa.re form.

Third, it won't always be recognized to fetch open-graph data and you might not get this fancy card with your website's name/description/visual.

Don't think it's just small, underground platforms that don't support it yet. It happened on ProductHunt, Google Chrome WebStore, CloudFront, Twitter, Facebook, Slack, to name a few and it really doesn't help the internationalization of domain names.

Keyboards

This one is just minimal, and nothing can be done for this, I think. But some keyboards make it very difficult to type special characters, especially the US one. That's why I also bought the getfenet.re domain.

Small tips on how to type special characters on a US International — PC layout:

' then e = é
` then a = à
Shift + 6 then e = ê
" then i = ï
' then c = ç

Of course, you can combine the accent with many other letters.

Clipboard Watch

There is no event for the clipboard in Electron (Chromium), so you'll need to watch it yourself. And if you're using a setInterval for this, you'll see it slowly dying with your inactive app.

That's where powerSaveBlocker enters.

Destroyed BrowserWindow

When manipulating or doing stuff with an opened BrowserWindow, be very careful that it's still alive, especially if it's asynchronous.

Or you'll get hit by an exception.

Use this in every asynchronous piece of code.

Transparent Windows

I wanted to implement a see-through feature, being able to keep the window in front, but the cursor would cut through it to reveal what's behind. And let the user click through it as well.

It was even easier than what I first thought (or I was just being an idiot), it's actually just a combination of BrowserWindow's configurations and some CSS sorcery 🧙‍️:

Main and Renderer process code for see-through feature.

Using the app as a MacOS service

In my journey to make this app the most deeply integrated into the OS as possible, I wanted to have it registered as a MacOS service.

Unfortunately, Electron's team doesn't find it important enough to put it in the core (yet?).

Which is a shame, or maybe, just not enough people care about it yet.

Next step will be to implement a native Node module I guess.

Reducing package size

When shipping Electron with your app, you're getting a pretty huge deal of a package. Electron alone will add ~117MB to your package 🏋️‍♀️. So the more you'll remove, the better.

Webpack

A good way to have a smaller sized bundle would be to have a build system. I've chosen Webpack, because I'm familiar with it. But any other would have worked of course. Grunt, Gulp or any basic concatenation of files (if you're that barbaric)...

Webpack lets you target both electron-main and electron-renderer. This way, with only one webpack.config.js you can output both your main process and your renderer process.

Going deeper with webpack, you can declare globals thanks to the DefinePlugin built in.

And, if you need to use absolute paths from within your app's package using node's path (for plugins for example), you should deactivate webpack's __dirname mock.

Here's a simplified version of my webpack's configuration:

Snippet of my webpack config. Showing dual output, _dirname obfuscation and globals definition.

Then run webpack --env.IS_PRO --env.IS_PROD --env.IS_PACKAGED depending on which build you need to create.

Having those globals helped considerably keeping a single codebase with different codepaths:

IS_PACKAGED : helped with the declaration of absolute paths. For plugins for example.
IS_PROD: helped with adding debug points and debugger only in development.
IS_PRO: helped with obfuscating pro features.

Closing tip. Register all your dependencies as a devDependency will help with the packaging. Using electron-packager it will completely discard your node_modules folder and only keep your bundled JavaScript when packaging your app, reducing the size considerably.

Languages

Without cleaning, you'll end up having all languages listed on your app's page.

Electron adds a .lproj folder for each supported language, for reasons. It will clutter your application's page on the Mac AppStore and will communicate wrong information about your app being internationalized in all these languages.

You can remove them yourself after the packaging of your app. To only keep the ones you support:

Icons

When you iterate on your designs, you might need to update your icons quite a lot. And generating those can be a pain, since you need _many_size and format. Especially this icon.icns for which many apps can ask up to 5$ to generate.

To ease this process, I've used this script coming from this awesome SO answer:

Here's the 5$ script.

Basically, just use it as ./icons.sh <input_file> <output_folder>, it is important to note that your input file _must_be at least 1024px in both directions.

If you need to upscale it to a 1024px square, you can use ImageMagick:

Unsupported videos

Chromium only support a small set of video format. Mostly mp4 and its derivatives. So if a user wants to play an .avi video, it won't work, because it doesn't work in Chromium... bummer.

Since I'm just using a basic <video> tag to load all local videos, I'm stuck with this. Except... that's my app, and I can do whatever the fuck I want, if I want to support more video types, I will, try and stop me.

Fortunately for us, we can listen to errors on the video, and even luckier for us, we can target missing support errors:

From there, in Fenêtre, I'm sending a ping back to the main process saying that I can't support this video type. The local server will create a new route for this video file and decode it on the fly using fluent-ffmpeg and stream it back to the renderer process:

Finally, simply update your <video>'s src attribute with the newly created route.

The only down side is that you need to ship ffmpeg with your app. And note that you have to compile it yourself with the --disable-securetransport flag, otherwise it will be rejected by Apple since it's using the Security API that isn't available while sand-boxed.

I was stuck at this point for a really long time, since I couldn't compile a static executable of ffmpeg.

But the issue was that OSX kept dynamic libraries in /usr/local/bin which all take precedence over everything else. So even if you try to compile your ffmpeg statically, it won't work with these libraries on the way as they will be linked to your executable.

So you have to move all those /usr/local/bin/*.dylib somewhere else, compile the static executable, and TADAAaa... the build will work in the sandbox.

See? It wasn't all that bad, you're still here, up and reading. How about we Ship it now?

Electron on the App Store, Early stages.

Yoann Moinet — Tue, 09 Feb 2021 21:40:27 +0000

This article is part of a 5 articles series about the publication of an Electron application into the Mac AppStore, Fenêtre.

Fenêtre, fənɛtʁ, lets you better multitask on your mac. It enables a picture-in-picture mode for any website/web-app, image, video or flat file.
You can find the free versionand the paid version on the Mac App-Store.

My name is Yoann Moinet.

I'm a French 🇫🇷 Senior Software Engineer at Datadog since 2019.

Writing JavaScript since 2007, I started programming professionally as an ActionScript (Flash ⚡️) developer in 2011 at Cossette (Montréal based advertising company) and then at Autodesk on 3dsMax in 2013 as a Web Application Engineer, later at Zendesk in Montpellier, starting in 2016.

I wanted to do a post-mortem article on my journey, my stress, my joy and my frustrations conceptualizing, developing, packaging and publishing an Electron application on the Mac AppStore.

It was a lot of pain and tears, but in the end, I really think it was a positive and teaching experience.

So much that I ended up writing too much content for just one article and decided to split it into 5 different articles, to ease the pain of reading that much content coming from a Frenchie blabbering in English, about his shitty experience with programming.

Inspiration

It all started in early 2017 when a colleague of mine showed me Helium . A very nice piece of software that lets you have a floating window in front of everything else.

In the following months, I've used it extensively, listening to talks and watching Netflix while coding (please, don't tell my boss 🙏). But, the more I used it, the more frustrations grew in me. It was missing very niche features I needed. Like a see-through mode, the ability to load local files, a markdown viewer, some code highlighting, more embeds and custom shortcuts...

Proof of concept

In the mean time I also wanted to learn more about the Mac application's ecosystem, packaging, submission and review loop.

So, in June, I started working on a proof of concept to see if I could have a similar feature-set quickly, with a technology I knew well, JavaScript.

Electron to the rescue (👋 haters), since all I wanted, primarily, was to load a website in a window, it was very relevant to use a web-view framework.

A week later, working late hours at home and supporting my very pregnant wife 🤰🏻, I had a first, very rough, PoC, a logo and a minimal feature set. That's all I needed to keep the motivation going for the next 6 months or so (TBD).

Very first prototype of Fenêtre.

This video helped me hook my colleague, Max William Neilson, the biggest Beyonce fan ever, and convinced him to do some designs for Fenêtre. Starting with the logo. Then, the website and the settings screen of the application.

Logo evolution, from my first try on the left to Max's latest, awesomest one.

From there I was able to make a nifty little animation in CSS:

Cost

This was a side project, so I wanted to have something with minimal cost and maintenance possible (because I'm cheap and lazy). That's why I chose to publish it on the Mac AppStore, following the great advice from another colleague.

At first, I wanted to handle both licensing and updating myself, but for the small price of 30% of everything, Apple can handle that for you.

All in all, the application cost me ~115$ (+30% of all sales), which is a fair investment in my opinion... of a cheap person.

Apple Developer License 99$: this is mandatory if you want to publish your app on the AppStore.
Domain name ~15$: I had to buy fenêt.re to deliver the website. Some people were having an issue typing the "ê" character, and MANY services still don't support it correctly (more on this later). So I finally bought getfenet.re as well, which brings the final cost to 30$, but it's still an exceptional cost.
Private git 0$: I'm using GitLab which offers private repository for free as well as other very neat features, like a CI.
Hosting 0$: Since I wasn't handling licenses or updates I didn't need any infrastructure for these. The only hosting I needed was for the website, which is a simple GitLab Page.

That was all fun and games, wasn't it? Now, come to the dark side and get your hands dirty, come cry with me in the next part of this series, Pain & tears.