React Event Delegation in v17/v18: Improving Performance and Isolation

You are in a system design interview at Meta for an IC4 role. The interviewer leans in and asks: "If a photo is already on my phone, how can WhatsApp still delete it when the sender taps Delete for Everyone?" Here is how you should break it down 👇 A lot of people think “Delete for Everyone” means WhatsApp somehow reaches into your gallery and erases a file from your device. That is not really what is happening. Btw, if you’re preparing for system design/coding interviews, check out my free mock interview tool on Layrs. You can use it for free here: https://lnkd.in/gpCn7t2T The real answer depends on where the photo is stored, how the chat app references it, and what exactly the app is allowed to delete. 1. First clarify the product behavior Before jumping into architecture, say this clearly in the interview: There are two different cases here. a) The photo exists only inside the chat app’s managed storage b) The photo has already been saved to the user’s gallery / camera roll / filesystem This distinction is everything. If the photo is only inside WhatsApp’s controlled storage, the app can remove the local file and remove the message reference from the chat UI. If the photo was exported or auto-saved to the gallery, WhatsApp usually cannot reliably delete that copy, because that file is now outside the app’s normal ownership boundary. So “Delete for Everyone” is mostly about: - deleting the message record - deleting the media attachment reference - deleting any app-managed cached copy - syncing that deletion event to all participants It is not magic remote file deletion across the whole phone.  2. High-level idea The clean way to think about this is: A chat message is metadata plus optional media. For a photo message, the system usually has: - message_id - chat_id - sender_id - media_id - timestamp - status - optional encryption metadata And the actual photo itself may live in: - encrypted object storage on server for temporary delivery - app sandbox / local database / media cache on device - optionally the user’s gallery if exported When sender taps Delete for Everyone, the system does not chase every byte everywhere. It sends a deletion command tied to the message_id.  3. What happens when the photo is first sent Here is the send flow: 1. User picks a photo 2. App encrypts media and prepares message metadata 3. App uploads encrypted media blob or sends it through media pipeline 4. App sends message metadata referencing that media 5. Receiver downloads the encrypted media 6. Receiver stores it locally in app-managed storage 7. Chat UI shows the message by resolving message_id -> media_id -> local file Read rest of the post: https://lnkd.in/gpv-wGze

This is the third article in my series on iOS interview preparation, where I break down topics that come up regularly and try to explain them in a way that reflects how they work in real applications. This time I focused on the app launch process, specifically what happens between tapping the icon and seeing the first screen. It is one of those topics that sounds simple until you start unpacking it. A typical explanation begins with the difference between cold start, warm start, and resume. In a cold or warm start, the system creates a new process. In a resume, the process already exists and the app returns to the foreground without going through the full launch path. From there, the system initializes the process and hands control to the dynamic linker. This is where the executable and its dependencies are loaded into memory. A significant portion of launch time is spent before any application code runs, which makes pre-main behavior an important part of performance discussions. After pre-main completes, execution reaches main, which calls UIApplicationMain. UIKit creates the UIApplication instance and the AppDelegate, then begins delivering lifecycle events. At this stage, the application starts participating in its own launch. In modern apps that use scenes, UI setup moves into the scene lifecycle. The system connects a scene, creates a window, assigns a root view controller, and prepares the view hierarchy. Once layout and rendering complete, the first frame appears on screen. From a performance perspective, it helps to think in terms of phases. Pre-main work includes dyld and runtime initialization. Post-main work includes delegate callbacks, scene setup, and UI rendering. Understanding where time is spent makes optimization decisions much more straightforward. I go into more detail in the article, including how launch time is affected by dependencies, static initialization, and early UI work. Link in the comments.

⚛️ Top 150 React Interview Questions – 149/150 📌 Topic: ⏳ Starvation in Concurrent Mode ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHAT is it? Starvation happens when low-priority updates are continuously delayed because the main thread is busy handling high-priority updates. Example: • High Priority → Typing, clicking • Low Priority → Rendering a huge filtered list If urgent updates keep coming, background work keeps getting postponed. That delay is called Starvation. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHY does it happen? ⚡ Priority-Based Scheduler (React 18) React assigns priority levels to tasks. User interactions → Highest priority Background rendering → Lower priority 🧠 CPU Congestion Heavy calculations + rapid input = background work feels “stuck”. 🎯 Responsiveness First React prefers keeping the UI interactive instead of finishing heavy tasks. Better a delayed list than a frozen input field. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 HOW does React handle it? React’s Scheduler assigns expiration times to tasks. If a low-priority task waits too long → React upgrades its priority automatically. That prevents permanent starvation. ✅ Example using useTransition const [isPending, startTransition] = useTransition(); const handleChange = (e) => { // 🔥 High Priority: Instant input update setVal(e.target.value); // 💤 Low Priority: May be delayed startTransition(() => { const data = heavyCalculation(e.target.value); setList(data); }); }; Typing stays smooth. Heavy list rendering runs in the background. If user keeps typing → list update may be postponed. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHERE does this matter? 🔎 Instant Search Typing fast while filtering thousands of results. 📊 Complex Dashboards Multiple widgets updating simultaneously. 🎞 Smooth Animations (60fps) Ensuring animations aren’t blocked by data processing. Concurrent Mode protects user experience first. ━━━━━━━━━━━━━━━━━━━━━━ 📝 SUMMARY Starvation is like a Busy Emergency Room 🏥 Doctors (React) treat heart attacks (User Input) first. Minor cold patients (List Rendering) must wait. If emergencies keep coming, the cold patient waits longer. But hospital rules (Expiration Time) ensure everyone eventually gets treated. ━━━━━━━━━━━━━━━━━━━━━━ 👇 Comment “React” if this series is helping you 🔁 Share with someone mastering React 18 concurrency #ReactJS #ConcurrentRendering #React18 #WebPerformance #FrontendArchitecture #Top150ReactQuestions #LearningInPublic #Developers ━━━━━━━━━━━━━━━━━━━━━━

Candidates use pub/sub and message queue interchangeably in interviews. But they're different tools for different problems. Pub/sub systems broadcast events to multiple subscribers. They prioritize low latency over guaranteed delivery. Message queues distribute work to exactly one consumer per message. They prioritize guaranteed delivery over speed. 𝐖𝐡𝐞𝐧 𝐭𝐨 𝐮𝐬𝐞 𝐩𝐮𝐛/𝐬𝐮𝐛 𝐢𝐧 𝐲𝐨𝐮𝐫 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰 📺 𝐅𝐚𝐜𝐞𝐛𝐨𝐨𝐤 𝐋𝐢𝐯𝐞 𝐜𝐨𝐦𝐦𝐞𝐧𝐭𝐬 — Viewers post comments that broadcast to everyone watching. Multiple clients consume the same event. Missing one comment isn't catastrophic. A pub/sub system handles this cleanly. 🔔 𝐏𝐮𝐬𝐡 𝐧𝐨𝐭𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧𝐬 𝐟𝐚𝐧-𝐨𝐮𝐭 — An event like "new like" needs to notify multiple downstream systems (mobile push service, email service, analytics). This is broadcast behavior. Low latency matters more than guaranteed delivery. 📈 𝐒𝐭𝐨𝐜𝐤 𝐩𝐫𝐢𝐜𝐞 𝐮𝐩𝐝𝐚𝐭𝐞𝐬 — Robinhood broadcasts price ticks to many connected clients. If one update is missed, the next arrives milliseconds later. Guaranteed delivery would add overhead without benefit. ⌨️ 𝐓𝐲𝐩𝐢𝐧𝐠 𝐢𝐧𝐝𝐢𝐜𝐚𝐭𝐨𝐫𝐬 — Slack shows when someone is typing. These events are time-sensitive and quickly stale. No need for persistence. Pub/sub broadcasts events to many consumers or many clients. 𝐖𝐡𝐞𝐧 𝐭𝐨 𝐮𝐬𝐞 𝐚 𝐪𝐮𝐞𝐮𝐞 𝐢𝐧 𝐲𝐨𝐮𝐫 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰 💳 𝐏𝐚𝐲𝐦𝐞𝐧𝐭 𝐩𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠 — Stripe processes transactions where every payment must be handled exactly once. A queue like Amazon SQS supports guaranteed delivery with retries. SQS provides at-least-once delivery, so you need idempotency keys to handle potential duplicates. 📧 𝐄𝐦𝐚𝐢𝐥 𝐝𝐞𝐥𝐢𝐯𝐞𝐫𝐲 — SendGrid queues outbound emails. If a worker crashes mid-send, the message stays in the queue for retry. Systems like RabbitMQ persist messages and support acknowledgement-based retries. 📦 𝐎𝐫𝐝𝐞𝐫 𝐟𝐮𝐥𝐟𝐢𝐥𝐥𝐦𝐞𝐧𝐭 — Amazon queues orders for warehouse processing. Each order must be picked and shipped exactly once. This is work distribution, not broadcast. 🎫 𝐓𝐢𝐜𝐤𝐞𝐭 𝐛𝐨𝐨𝐤𝐢𝐧𝐠 — Ticketmaster queues seat reservation requests so that exactly one booking worker handles each request. No duplicate seat assignments. Queues distribute work reliably to one consumer per message. If losing a message is acceptable or you need to broadcast to many clients, use pub/sub. If every message must be processed exactly once, use a queue. https://lnkd.in/gvgfdrdm

⚛️ Top 150 React Interview Questions – 146/150 📌 Topic: 🧹 Cleanup Function Importance ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHAT is it? The Cleanup Function is the function returned inside useEffect. It runs: • Right before a component unmounts • Before the effect re-runs (when dependencies change) Its job is to undo side effects created by the effect. Think of it as a reset mechanism. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHY is it critical? 🧠 Prevents Memory Leaks Stops timers, subscriptions, or listeners from running after unmount. ⚠️ Avoids Illegal State Updates Prevents “Cannot update state on an unmounted component” errors. 🔒 System Integrity Releases global resources like WebSockets and browser listeners. Without cleanup → background chaos. With cleanup → controlled environment. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 HOW does it work? React automatically executes the returned function. ✅ WebSocket Cleanup useEffect(() => { const socket = connect(id); // CLEANUP return () => socket.disconnect(); }, [id]); When id changes or component unmounts → connection closes. ✅ Abort API Request useEffect(() => { const controller = new AbortController(); fetch(url, { signal: controller.signal }); return () => controller.abort(); // Cancel request }, [url]); Prevents updating state after navigation. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHERE is cleanup mandatory? 🔌 Subscriptions WebSocket, Firebase, Chat APIs. 🌍 Browser APIs window.addEventListener (scroll, resize). ⏱ Timers clearTimeout / clearInterval. 📡 Async Requests AbortController for pending fetch calls. Any persistent side effect → requires cleanup. ━━━━━━━━━━━━━━━━━━━━━━ 📝 SUMMARY The Cleanup Function is like Checking Out of a Hotel Room 🏨 Before leaving (Unmount), you must turn off lights and close taps. If you don’t, the hotel (Browser) keeps wasting resources. Cleanup ensures nothing is left running after you leave. ━━━━━━━━━━━━━━━━━━━━━━ 👇 Comment “React” if this series is helping you 🔁 Share with someone mastering useEffect #ReactJS #useEffect #MemoryLeaks #FrontendBestPractices #WebPerformance #Top150ReactQuestions #LearningInPublic #Developers ━━━━━━━━━━━━━━━━━━━━━━

A framework to structure an iOS system design interview: A lot of interviewers these days will try to pretend that your interview is a casual chat. Don’t be fooled. Obviously, act natural, smile, but it will never hurt you to introduce some formality via a framework. A framework is a simple structure you can follow to answer the problem. A reusable way of arranging your thoughts while you design the system. The framework goes like this: * Scoping * Functional requirements * Non-functional requirements * Data model * API design * High-level design * Drill-down questions With system design, “measure twice, cut once”. You must understand the problem space and what needs to be designed before you draw anything. As iOS developers, it’s tempting to dive straight into SwiftUI vs UIKit, MVVM vs MV vs VIPER, and your favourite concurrency toolkit. That’s a dangerous game: the system design interview is far more about data flow and structure than UI or frameworks. Now let’s look at a full worked example of an interview, demonstrating how to tackle the interview systematically. This might be the best prep out there, because it’s based on three of the real final-stage panel interviews I did last month. My worked example takes you through the most popular system design question out there today. By the end, you’ll have the confidence to tackle your own iOS system design round. Get practical battle-tested advice on getting through mobile system design interviews right here 🧠 https://lnkd.in/ehr5UpzX

You can pass React interviews even if you’ve never built a massive React application. Most interviews don’t test how big your project was. They test whether you actually understand how React works, even when the code is written with the help of AI. Here are the kinds of React questions that show up repeatedly in interviews. ➤ Common React Interview Questions 𝗕𝗔𝗦𝗜𝗖 𝗟𝗘𝗩𝗘𝗟 1. What problem does React solve compared to vanilla JS? 2. What is JSX and how is it transformed under the hood? 3. What is the difference between props and state? 4. What is the purpose of the key prop in lists? 5. How does event handling work in React? 6. What happens when state updates in a component? 7. How does conditional rendering work in React? 8. What are fragments and when would you use them? 9. What are controlled inputs in React forms? 10. What is lifting state up and why is it useful? 𝗠𝗢𝗗𝗘𝗥𝗔𝗧𝗘 𝗟𝗘𝗩𝗘𝗟 11. What happens during a React re-render? 12. What is the difference between useMemo and useCallback? 13. When should you use React.memo? 14. What problems does the Context API solve? 15. What is prop drilling and how can you avoid it? 16. What is the difference between client-side routing and traditional routing? 17. How do you structure state in a medium-sized React application? 18. What is code splitting and how does React.lazy work? 19. How do you debounce expensive operations like search inputs? 20. What is the difference between controlled and uncontrolled components? 𝗔𝗗𝗩𝗔𝗡𝗖𝗘𝗗 𝗟𝗘𝗩𝗘𝗟 21. How does React reconciliation work? 22. What is the diffing algorithm in React? 23. How do you prevent unnecessary re-renders in large apps? 24. What are Server Components and when would you use them? 25. How does streaming SSR work in modern React frameworks? 26. What are error boundaries and where should they be placed? 27. How would you structure authentication and protected routes? 28. How do you manage global state in large React applications? 29. How do you debug performance issues in React? 30. How would you design a scalable folder structure for a large React codebase? 𝗔𝗜-𝗥𝗘𝗟𝗔𝗧𝗘𝗗 𝗤𝗨𝗘𝗦𝗧𝗜𝗢𝗡𝗦 (𝗡𝗼𝘄 𝗦𝗵𝗼𝘄𝗶𝗻𝗴 𝗨𝗽 𝗶𝗻 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄𝘀) 31. How do you use AI tools during development without blindly trusting generated code? 32. How would you verify if AI-generated React code is correct or performant? 33. What parts of a React workflow can AI realistically speed up? 34. What risks come from relying too heavily on AI-generated code? 35. How would you debug code that was generated by an AI assistant? These questions show up again and again across frontend interviews. That’s exactly why I created the Frontend Interview Playbook, a structured guide that covers React fundamentals, machine coding patterns, frontend system design, performance engineering, and how to use AI properly during preparation. You can check it out here: https://lnkd.in/d8vBd3_j  Use code FRONT10 for 10% off.

Tricky iOS interview questions: In which cases will value types be stored in the heap, and references in the stack? Hello! My name is Andrey. I’m a seasoned iOS developer with more than 9 years of experience. During my career, I’ve attended tons of technical interviews and was asked plenty of questions, the answers to which were not obvious to me at first. To help you avoid mistakes I’ve made, I’m starting a new series of posts in which I’ll explain those tricky questions so you can smash that tech interview! Subscribe to receive useful weekly content, stay in touch, and not miss anything! The first question I am going to explain is: “Do you know cases when value types will be stored in the heap, and reference types in the stack?” That’s a pretty tricky question I’ve been asked frequently during iOS technical interviews. First, let’s start with cases when reference types are stored in the stack: - A reference type may be stored in the stack when an object of a class is declared as a local variable within the scope of a function. - A reference type may be stored in the stack when the object’s size is already known by the compiler, so it will place it inside the stack as an optimisation. And now there are cases when value types are stored in the heap: - A struct that is very large and doesn’t fit into the stack will be placed inside the heap. (The stack has its own limits in terms of the size of contained objects.) - When we expect a protocol type from the struct (and also when struct doesn’t fit itself into three machine words). - When a struct contains a field of type Any. - When a struct is a property inside some class. - If T is a reference type, then all structs of type MyStruct<T> will be stored inside the heap. That’s all the tricky cases about stack and heap placement. By reading this, you’ve become more proficient in terms of iOS memory management, and you’re able to crush this tricky interview question! Subscribe not to miss more tricky interview question answers, and if you have any questions for me, feel free to ask them in the comments! Happy coding and interview preparation!

performance-code-splitting-interview-q Interview Trap Alert: "Code splitting makes my site faster." 🚫 If you stop there, you're missing the nuance that separates Juniors from Staff Engineers. It's not magic; it's a strategic trade-off. Here's the Senior-level breakdown: 1️⃣ The Metric Shift: By splitting bundles, we don't just "speed things up." We drastically reduce the `initial JS payload`, directly boosting `FCP` (First Contentful Paint) and `TTI` (Time to Interactive). Benchmarks show 40-70% reductions in bundle size. 2️⃣ Strategy Matters: It's not just `React.lazy()`. You need to decide between `route-based` splitting (for SPA navigation) vs. `component-based` (for heavy modals/visualizers). The wrong choice leads to unnecessary re-fetching. 3️⃣ The Hidden Cost: Over-splitting creates `network waterfalls`. If you split too aggressively, you trigger too many parallel requests, overwhelming the `TCP` connection or causing `HTTP/2` overhead. The goal is optimal chunking, not maximum fragmentation. 4️⃣ The 2026 Standard: Modern tooling like `Vite` and `Webpack 5` automates much of this, but you must still configure `dynamic imports` (`import()`) and ensure `tree-shaking` is active to remove dead code. Master the balance, and you turn a loading spinner into a seamless experience. Found this useful? Follow for more such interview questions and save post for your next prep session! #Performance,#WebDev,#Interviews,#CodingTips,#Frontend