> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
This is what stood out to me. I've never really suspected webviews and can't think of a place now.
I often suspect things in Settings, esp. account/iCloud section to be webviews, just based on how they load (icons appearing a short moment after the page opens for example).
When you tap some of the menu items in the “Saved to iCloud” section, they don’t have the normal grey item highlight that happens with the rest of the settings app.
I’m sure there are many apps like the Apple Store app and parts of the App Store that pull in web views. That’s most likely what this is for. Probably parts of News, Music, Games apps as well.
Actually it does not. It used to, but then was rewritten. The Accessibility Inspector app can be used to see what's the class of the UI elements, if you want to check.
I think it still might. I use it all the time on my laptop, and periodically if I do something funky with the network, the entire view panel says that there was an internal server error in that classic no-CSS Times New Roman font. Do you have a source for this?
Mailpit works amazingly for us. Thanks to it having a very simple API, we've been able to integrate it into Playwright e2e tests, and can easily verify things like complete new user registration and password reset flows in seconds. And the UI is handy for local dev work.
There's no rush to move away from MailCatcher or MailHog, but if you're not using those solutions already I see no reason to use them over the maintained options.
> I see no reason to use them over the maintained options
Things that don't change over a longer time period can be more comfortable sometimes. Especially things you use often and build up a sort of "muscle memory" about.
Yeah, people underestimate the value of “finished” software: in an ecosystem with lots of stable dependencies, there’s very little reason for useful software to change constantly.
Even "finished" software needs maintenance. Nothing is ever bug-free so needs fixes. And it doesn't live in a vacuum, the ecosystem evolves and continuous adjustments are needed when APIs evolve or libraries change.
In well-written software, the maintenance burden is low, but it's not zero. Without any maintenance, you can maybe run some piece of software in some closed-off container for a while, but it will keep rotting away and eventually you won't even be able to compile it anymore.
What about "GNU Hello", never finished? Clearly this isn't true for 100% of all software, so the only thing we can conclude is that it either "depends" and/or is very subjective.
> when APIs evolve or libraries change.
If you live/work inside an ecosystem that favor stability over "evolving APIs", you can actually be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too.
Does "small burst of activity and dependency updates twice a year" seem inadequate to you? That's the scale of maintenance that the project in question seems to exhibit, which is what we're apparently calling not maintained.
Commenter was just making the fair point that the dependencies are out of date.
Maintenance doesn't always mean UI redesigns or non-compatible config changes. Sometimes it is just fixing bugs and updating or replacing old dependencies.
Easy REST API access can be a quite useful feature too.
For automated integration testing it's a must. The test can verify in the end if the expected emails were sent out.
I think Mailpit can even be set up as a real SMTP server, handling a (sub) domain. Either as a MX or just via forwarding rules. Sometimes it can be useful to periodically run integration tests on a production system. So your tests could create accounts based on your test domain (random-user-name@testsystem.company.tld), which is deliverable from every email server, and the tests can verify the delivery. An automated script can then periodically delete the *@testsystem.company.tld accounts.
It really only likely matters if you're one of those who is tempted to let it run on `0.0.0.0` instead of loopback only.
Assuming you're not, there's certainly no urgency to migrate. But keep it in the back of your mind that it's unmaintained, and if things go weirdly wrong during an OS or ruby upgrade, remember that you will need to fix it or pick up something else that's kind of similar.
If you're not already using it, it might be a good idea to pick up something else.
I like [mailpit](https://github.com/axllent/mailpit) because it's a single static binary and because it has a nice api I can use during testing to see if a message made it out of the system I'm testing.
But none of that argues for switching away from a thing that's working for you.
It depends. If it's not exposed to a network and doesn't have any awful bugs, than it should be fine.
Usually those mailtrap servers have some exposure to the company intranet or sometimes the internet, which could be problematic. Even test systems might receive sensitive data in the emails, that shouldn't be leaked to an attacker. An unmaintained software might have well known security issues.
For those that don't want to run a SMTP server, I built Ephemeral Postal which offers a basic API for polling a mail box and retrieving messages, along with an in-browser UI. You get an entire subdomain to yourself that will take any address that you throw at it. https://ephemeralpostal.com
What’s the easiest way to receive email programmatically without having to resort to a hosted service like SES? Is the SMTP protocol simple enough that it can be implemented in for example a serverless lambda?
The easy answer is to use an smtp server; many languages have stable packages to implement that.
You can also use postfix with procmail or exim - leave the smtp stuff to tried and true packages, and have your code receive messages either via maildir or direct scripting.
The long answer is: first make sure you don't have a blacklisted IP; ask your cloud provider for permission to enable an MTA (mail transfer agent) and have fun seeing 99% of your email traffic being either brute force auth attempts or spam delivery attempts.
The protocol is quite simple to implement. The tricky part is triggering the lambda and then holding the connection open long enough to get the message.
You can’t trigger a lambda directly via tcp. You’d have to go through a gateway. That gateway would have to hold both sides of the connection open for a pretty long time.
If you're building a system that sends out emails, you generally can't send emails locally. So you instead use a service like MailCatcher/MailHog/MailPit/Mailtrap as an SMTP server that will "catch" the emails as they are sent. Then you just open that app up and you can see what emails were sent, what their content is, who they were sent to, etc. Some of these services also include email evaluation tools for things like identifying unsupported HTML/CSS, checking image/message sizes, headers, etc.
The other use case is when you're in a staging environment. You should generally seed such environments with fake email addresses but you can never be sure those emails are truly fake, and you can never be sure what email addresses your testers are using. So you set up MailPit and A) you never send a real person a fake email accidentally and B) all testers can see all emails.
It seems like almost everyone has written an SMTP server; I use https://github.com/tijn/devmail which has no web interface but a POP server. This is by design so you can see your mail in an actual mail client like Apple's Mail.app or Thunderbird.
Open-source is good for solo and small projects, but there are commercial solutions with continuous support, etc. and other features (e.g. SMS) like Mailosaur too
> The original Node-RED Dashboard is based on Angular v1, which is no longer maintained. Although small patches have been and will continue to be applied on a "best can do" basis, there will be no major feature upgrades. The lack of ongoing maintenance and updates has the potential to lead to underlying security breakages, a risk we are not comfortable taking. We have recognized the need to innovate and adapt, which is why we are creating a completely new project to replace the existing Node-RED Dashboard.
