April 1, 2026
Roll the dice, rage in the replies
Randomness on Apple Platforms (2024)
Dev guide says use the newer random tool; commenters roast the old one and spot a typo
TLDR: A new guide shows Apple developers should ditch the old “rand” and use the system’s modern random generator for safer, better numbers. Readers cheered the clarity, mocked the old tools, nitpicked a typo, and debated whether to keep it simple or dive deeper—because security and speed both matter.
Apple devs are buzzing over a deep-dive that basically says: stop using the ancient “rand” and go with the modern, system-backed random generator. The post walks through decades-old functions, then lands on Apple’s preferred pick—think of it as the house-recommended dice—and even peeks under the hood to show it’s regularly refreshed by the system. For non-devs: the takeaway is simple—better randomness = better security.
But the comments? That’s where the fireworks are. Many cheered the clarity and the “aha” diagrams, with one camp chanting “just use the built-in and move on,” while others argued for different layers like Swift’s built-in Random or Security framework calls. The old “rand” function got dragged like a relic from the ‘80s, with jokes about seeding it with a clock and hoping for the best. A tiny typo—“corecryto” instead of “corecrypto”—somehow stole the spotlight, spawning nitpick memes and “spellcheck-as-a-service” jokes.
Security-minded folks warned against DIY randomness, insisting the system’s trusted generator is the only sane choice. Performance hunters claimed they just want fast numbers for games, not bank vaults. And in true dev-forum fashion, the loudest meme was basically: don’t reinvent dice—just roll the one Apple already fixed.
Key Points
- •rand(3), random(3), and rand48(3) are legacy RNGs on Apple platforms and are obsoleted in favor of arc4random(3).
- •arc4random(3) uses a cryptographic PRNG with a per-process pool, reseeded from the kernel RNG regularly and on fork(2), and works in chroot(2).
- •arc4random_buf provides a fundamental interface for obtaining random bytes, and arc4random_uniform supports bounded uniform values.
- •Legacy RNG implementations date back to the 1980s, with minimal changes since the 1990s/2000s and derive from FreeBSD’s libc; they require explicit seeding.
- •Apple’s libc implementation of arc4random initializes via ccrng() to obtain an RNG handle and crashes if acquisition fails.