And it will be 300$ if you are a company. If you don't have a company account, you can't really work in team because of how signing apps work.

That’s for an enterprise account, used for internal release apps (not test!). Enterprise accounts are often misused by companies that just want to abuse the device provision list, it’s not required.

I’ve built widely downloaded apps for companies, featured in the App Store, with a small team of devs sharing one standard $100 account.

Any successful projects you can show so everybody knows you are as effective as you want to be ?

There is a 5g specification called 2D2 which is an acrobym for device to device. Could we create a "p2p" network so we don't need to all pay provider to get internet but rather share bandwidth ?

That's all right and all fine. It's my user choice to install any crappy third party app store on the hardware I bought. I would like to not being protected. The same on windows, I'm warned than executing an unknown program is a risk for me and if I don't know what I do, then I should not do it. That is perfectly fine. Small fences with warning signs instead of 10 meters walls.

User choice works the other direction as well: that consumers can choose to knowingly purchase a device that is locked down, for reasons of safety, trust, experience, etc.

I happen to broadly favor anti-trust intervention against Apple in this instance; but it's not as though Apple ever deceived users about what their devices can and can't do. They sell appliances, not "computers". Freedom (arguably) includes the freedom to take one's own freedoms away, at least up to a point.

I agree with this. I pay for the experience Apple delivers. I don’t want an open mobile device, or a free (as in software) mobile device. It’s my hardware but I agree that Apple dictates the terms and delegate them the authority necessary. I want a curated experience and pay a premium for it, after tolerating the rough edges of Android for years.

I’m generally fine with the general lockdown on iOS, but at the same time there really are only two smartphone players. It’s either the free-for-all Android or the rigid-reviewed apps on iOS. Given the market realities having at least the ability to side load apps should be allowed. Apple can still offer their curated experience, but I should also be able to add my own open source (or whatever) App Store without Apple’s blessing. Just because I generally like Apple’s approach on the App Store doesn’t mean I shouldn’t be able to “mod” my own hardware. It’s like if I buy a BMW because I like their quality, integration and security that’s fine, but I still want to be able to replace the stereo if I choose. Actually I think it’s my right since I own the hardware, no? Or better, if I install a Sirius XM radio in my car why in the world should Sirius be forced to pay BMW for that “privilege”? If they want to integrate into their pre-made BMW stereo system sure, but I want to be able replace that with my own stereo.

Then don't use non-Apple App Stores. You don't get to decide whether other people have a choice or not.

The problem with such a „soft“ system as opposed to a hard sandbox is that rules may change after you purchased the phone and rules get applied inconsistently. Both happens regularly.

I strangely use storybook with cypress for react native ui testing automation. Also to get multiple screen size on the same screen to check everything is done properly.

I didn't intended to share the repo but as HN is talking about storybook, here it is. Not ready for prod, many todos but the storybook/cypress is demonstrated here.

https://github.com/Fr33maan/react-native-ui-real-boilerplate

Why this has been downvoted ?

My hero! Bro who is going to be the voice of reason in this crazy mixed up world? If I were an archaeologist in the future I'd start by reading all the most downvoted comments for sure!

starred, Im curious if it could run concurrently with a standard tool to see impact on performances.

It’s just a reference to the Mean Girls movie. Works well with haskell’s kind → mean.

ok I do understand why I didn t understood

Is mentioning women off limits nowadays? Come on. It might as well been "Kindness for Mean Boys" and the meaning and implications of it would not change a single iota, except losing the movie reference and light tone the author wanted to go for.

He's drawing a comparison between Haskell kinds and concepts shown in the (once) popular teenage movie "Mean Girls".

It’s still pretty popular, it does have kind of a cult-movie status.

s/He’s/She’s/

It's a jokey reference to the movie Mean Girls (a comedy).

No such stereotype says only women are mean.

I don't know the movie, so I agree with the title being a bit strange, and I probably could have done with a slightly more factually oriented article, but I appreciate the effort to keep it light. And the stereotypical girls' cliques the article seems to riff on do exist... Girls are known to be more relationally aggressive than boys, who tend to be more physically aggressive than girls. Girls also behave in a more pro-social fashion, so girls' cliques are often larger than boys' cliques, creating more complicated power dynamics. That said, I don't really get what you mean. That's like saying a book called "Good Habits for Incompetent Managers" reinforces the stereotype that only managers are incompetent.

It's funny how often the people "fighting" a stereotype are the people that bring them up in the first place and thus spread them.

I've never heard a stereotype that suggests only women are mean. Perhaps it's a cultural trope?

They are referencing the old idea that men handle disagreement with violence while women handle it by being mean to each other. Saying "only women at mean" is hyperbolic, but they likely are stereotypes.

For what it's worth, I've never considered meanness to be limited to non-physical attacks. I'd venture to say a bully punching a kid is just as likely to get labeled mean as a bully that makes fun of a kid.

Never heard of a stereotype according to which only women are mean.

finally a specification for datagrams, unordered and unreliable ! This was one of the big struggles of bringing mmo to the browser. DatagramTransport seems really promising as it provides encryption and congestion control which are the most complicated parts of any netcode. Good luck !

This was one of the big struggles to bring anything remotely time critical to the browser.

WebSockets only works for the mere basics.

SCTP already provides that in WebRTC.

But requires a lot of mucking around with STUN/TURN/ICE, which is far less desirable than just "send UDP packets to a browser".

You don't need to use STUN and TURN for client->server use cases, but you do need ICE, DTLS, and SCTP.

WebRTC is known complicated to set up and quite unstable. Many companies have made a business of configuring WebRTC.

You can create a WebRTC datachannel in any modern browser with just one line of javascript:

     channel = new RTCPeerConnection().createDataChannel("foo", {ordered: false})

Then you can read from it with:

     channel.onopen = () => { ... }
     channel.onmessage = (event) => { ... }

This is widely supported in every modern browser.

What about the STUN, ICE etc stuff? Saying “you just open a connection” is only part of the story.

If you are talking to a websocket like server endpoint, hopefully it won't be behind NAT?

Actually, I'm currently working on an app using WebRTC, and from everything I've read you actually still need a STUN and in some cases a TURN server, even if you have a public IP:

https://bloggeek.me/turn-public-ip-address/

To be perfectly honest, I'm still fuzzy on the why, but numerous blog posts, stack overflow questions, and the Kurento forums agree. This being Hacker News maybe someone with chime in with the technical reasoning.

WebRTC negotiates a peer-to-peer protocol which operates like client/server but has issues with NAT/PAT and firewall traversal. Each peer will realistically only know about its local network and there will also likely be limitations on the peers even being able to communicate with one another directly.

STUN and TURN allow the negotiation to include services outside the local network so that you can relay signaling and stream data to a set of endpoints that both peers can use to communicate with one another. This could be the peers directly or it could be a set of 3rd party servers run by Google or someone open to the public and you can't assume any particular network topology.

This article is essentially claiming that for WebRTC to use TCP you have to be using TURN. While I am willing to believe I am wrong here (our product feels a bit crippled over TCP to the point where I just recommend you not use it, so if it isn't working I might not even notice), I am nearly certain this is not true.

You are right, ICE does support TCP. Not all ICE implementations support it though, probably where the incorrect anecdote comes from.

ICE TCP did get a little more limited recently in Chromium though [0] because of the TCP port scanning issue [1]

I have also heard that some gateways/firewalls/$x don't allow any non-TLS traffic, so you can't even establish ICE. In those cases the DTLS/TLS transport of TURN is nice.

[0] https://lists.w3.org/Archives/Public/public-webrtc/2020Feb/0...

[1] https://medium.com/tenable-techblog/using-webrtc-ice-servers...

You are probably right. But sounds like this would still be better solved by this light tweak to webrtc than by a new protocol.

Exactly. If WebSockets were an option, then WebRTC will be pretty trivial and absolutely doesn't require any STUN/TURN.

(The main issue, and this has nothing to do with the client API, is that WebRTC implementations tend to end up assuming unique ports for each user--which would be needed to help with NAT--but if you aren't behind NAT then the ICE layer already has a connection ID so you should be able to multiplex them all over a single open port.)

One big issue was also being able to demux DTLS traffic. You could do it off the 3-tuple of the remote host, but that would fall down sometimes.

I am really excited for DTLS connection ids[0] to land. Then you will have everything you need to run ICE+DTLS (and SCTP over that) and be able to demux/load balance it easier.

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connect...

This is simply not true. Unless things changed widely since I used WebRTC, this connects to nothing.

Leaving out the ICE will of course make WebRTC look palatable.

There pain point is running ICE, DTLS, and SCTP on the server.

> That sounds like you need better software then :)

No, it rather sounds like you have a hammer called WebRTC and you're attempting to use it on a nail called "bidirectional server/client communication".

Why deal with the complex protocol stack of WebRTC which solves, among other things, NAT traversal, mutual authentication and encryption independently of server certificates, multiplexing of data and A/V content on a single port and much more. And I say that as someone who absolutely loves WebRTC for A/V and secure P2P use cases.

There is a true gap of "UDP for the web", which this fills.

"WebSockets over UDP" don't need to be built on QUIC, but I'm assuming by the time you have added all the security features needed to make this as secure as WebSockets for web apps, you'll effectively end up with something equivalent.