Shadowing Practice: My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

239 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

In the last video, I presented web apps as an alternative to native mobile development.

The single biggest objection in the comments was about Electron.

The assumption that web apps are fundamentally broken and always result in enormous bundle sizes and poor user experience.

Well, I dislike Electron apps as much as you do, to the point where I can tolerate only a couple of them on my Mac.

And the smallest one is nearly 500 megabytes in size.

But here's my web app.

It's under 10 megabytes and rated 4.9 on the App Store.

In this video, I'll explain the difference.

More importantly, I'll show you how to build web apps

that offer a user experience comparable to Swift UIs and a developer experience that's far better than Swift UIs.

Oh, and you can deploy such an app in three minutes and without getting an approval from Apple or anyone else.

Does that sound too good to be true?

You're right to question this.

Replacing an Electron with WebKit wouldn't magically make your app better.

The web stack is full of hidden friction points that make unoptimized web apps feel wrong to mobile users.

So when you want a product that has the look and feel of a native app, first you have to make sure that the web app itself is fast, powerful and responsive.

And that's what we'll focus on today.

No native shells, no pin into the home screen, only a plain website.

But one that runs better than half of all SwiftUI apps and better than 99% of all wipe-coded garbage.

This video is not a coding tutorial, because you don't need my help to write a JavaScript function.

Instead, I'm offering you a deep dive into my apps architecture.

I break down its key aspects, explain my design decisions, and offer architectural advice you can apply to your next or your first web project.

And if you've got channel membership, today's extras include expanded explanations, more examples, and a detailed breakdown of my deployment process.

If you don't have a membership, no worries.

The public version of this video still includes everything important for getting started.

In case you missed the last video in which I explained the app's concept, Space Photos is my playground project.

It's a simple app that presents images of the universe fetched from NASA's astronomy Picture of the Day service.

It is super fast, works on screens of any size, and lets you build a collection of your favorite pictures.

In terms of software, Space Photos is built as a progressive web app.

It works in the browser as a plain website, on the home screen as a pinned app, and in a lightweight shell as a native iOS app.

At each level, it gains more native-like features.

The web app is completely self-sufficient and keeps everything in a single repo.

That everything includes the actual metadata for each space photo, its title, explanation text and media URLs.

In a larger or more complex app, I would probably keep production data in a separate place, perhaps a dedicated database.

But in this case, storing the JSON files in the same repo enabled faster builds and some useful build time optimizations,

while taking just 13 MB for over 30 years of space photos.

At this point, it seems that I can no longer avoid answering the question I got asked multiple times in the comments.

What specific frontend framework space photos is built with?

I didn't name it in the last video, because doing so requires providing enough context.

Now's the time.

I always say that any technology is just a tool, and you should pick the best one for your specific job.

I even put this in the channel description.

So let's first consider the functional and non-functional requirements of space photos.

First, if I want even the slightest chance to compete with native apps, the framework must incur as little overhead as possible while playing nicely with all the modern web standards.

Second, because this was actually my first serious web app, I didn't want to commit to any single framework, just in case I'll need to swap it for something else later.

That is why standard HTML syntax was preferred over any specialized tools like JSX.

Third, I enjoy clear separation of concerns, where business logic is or can't be entirely decoupled from the user interface.

Only when I had this list of requirements did I actually start looking at my options.

And while more than one framework matches this criteria, for this specific project I chose SvelteKit.

Here's why.

First of all, SvelteKit is not really a framework, but more like a compiler.

SvelteKit compiles down to vanilla JavaScript and has no virtual DOM.

At runtime, it is nearly as fast as bare handwritten code developed 30 years ago.

The bundle of a fully functional app is roughly 50 kilobytes in size, or about half as much when it's GZ.

SvelteKit's syntax is based on standard HTML.

You don't have to learn some new JSX or XML-like language, so if you decide to switch to a different framework in the future, you can reuse most of your code.

SvelteKit does not enforce any particular design pattern, but it fits the MVC and MVVM patterns quite naturally.

My personal preference is to do as much as possible in the server components, which are roughly equivalent to the controller in MVC.

Although in my app they're not really server components, but rather build time components.

My app is fully pre-rendered, which is another advantage.

The data flow is reactive, which is something I was cautious about at first, because of my poor experience with SwiftUI.

But in reality, SvelteKit's reactivity is much more fine-grained.

It doesn't update entire screens whenever something changes.

Instead, it's based on individual signals you're subscribed to, similar to Cocoa bindings.

And finally, I find SvelteKit's out-of-the-box experience very dev-friendly.

It ships with full support for routing, server-side rendering, static-side generation, and many other things.

If you only need the reactivity and reusable UI components, you can use Svelte alone, without the kit.

But so far, I've been quite content with the features and developer experience of the entire framework.

One aspect of that developer experience I should highlight specifically is the support for hot reloading.

This isn't something unique to SvelteKit, this feature exists in most front-end frameworks.

But I just can't stop appreciating how stable and reliable it is.

Updated pages refresh instantly and even keep any user input intact.

But if there's a syntax error, you'll get a warning immediately.

Try to achieve the same in SwiftUI.

By the way, maybe you heard that story where Apple accidentally leaked the sources of the App Store's web version.

Guess what front-end framework is built with?

That's right.

So, moving on from the developer experience to the actual development process, let's have a look at the core of SpacePhotos.

First, the overall approach to the app's layout.

When you want a good mobile app, you should build a mobile version first.

A single viewport directive disables the standard zoom out behavior, sets the scale to 100% and lets you use the screen parts outside the safe area.

The latter will be important when you run the app in the standalone mode with no browser toolbars.

Because I wanted to minimize the friction for my app's existing users, I decided to sort of imitate the familiar look of a typical iOS app.

This means my app should have a tab bar on the bottom and a and a navigation bar on the top.

Both are simple panels that sit above the main document and are pinned in place using the fixed position mode.

Importantly, because I made the panels appear semi-transparent and have a blur, the page content must scroll beneath them.

Both goals are easily achieved with only a few lines of CSS.

You see, HTML documents can be infinitely long, which turns the browser canvas into a giant scroll view.

When you reach the end of it, the entire document, including the bars, would exhibit rubber bending and can also trigger a page refresh.

This is what immediately gives away the true nature of the app.

In native ones, the bars always remain stationary, while the content can scroll, stretch, and bounce back.

And that is exactly how it works in my web app.

Things like this really do matter for the overall user experience.

And actually, they're not impossible to recreate.

You just have to care enough.

For example, I once had to subclass the UI components of Firebase in AppMessaging and extend them with native-like interactions.

I used UIKit Dynamics to add physics-based rubber bending and swipe to dismiss.

It took me quite a while to figure out the precise formula, but the resulting animations felt very familiar to iOS users.

They didn't have those uncanny valley vibes you often get with cross-platform frameworks.

100

By that point, space photos looked just right on mobile.

101

Bringing it to larger screens required only a couple of adjustments.

102

First, I limited the container's maximum width to 800 points.

103

I did it so the UI doesn't feel absurdly wild on large monitors.

104

This takes exactly one line of CSS.

105

And second, I configured the tab bar to move from the bottom to the top when the width exceeds a certain threshold.

106

This required only a couple of lines too.

107

The next point is the look and feel.

108

As I mentioned in my previous video, every UI element of space photos works equally well with all input methods.

109

Touch, mouse and trackpad.

110

In most cases, I didn't even have to do anything special because nearly every HTML element adapts correctly out of the box.

111

But there's a cache.

112

You have to use those elements according to their semantic rules.

113

For instance, the button element on the web is not really designed to take the user elsewhere.

114

Its purpose is to perform some local ephemeral action, open a menu, expand a section, close a model sheet, and so on.

115

And while it's totally possible to trigger navigation using buttons, this negatively impacts accessibility, which is quite important.

116

A more conventional approach is to use the standard anchor element, also known as the link.

117

You can style it to look just like a button, with background, padding, and whatever else.

118

Doing so automatically enables the behaviors you associate with links, the hover in active states, the pointer cursor, and the ability to open them in a new tab.

119

The button can't do this without a lot of extra code.

120

This is why most elements that look like buttons in my app are actually links.

121

This includes the tabs in the tab bar, space photo cards and thumbnails, and cells in the favorites list.

122

There are still places where I used plain buttons, mostly because I needed to trigger haptic feedback, but I'm working on turning them back into links.

123

Another aspect is navigation.

124

A typical single-page app or SPA is just that, a single page.

125

This offers the exact experience many of you associate with web apps, and I admit, it's not a good one.

126

First the SPA shows an empty template.

127

Then it displays a loading indicator and starts patching the data, which takes 3, 5, 10 seconds or even longer.

128

it shows the content, often after a flash of white or a jump in a layout.

129

At that point, you can finally see the content and interact with it.

130

You can even navigate to other screens, or so it appears.

131

To the browser, all this is just an opaque box that's doing something.

132

Every screen of the app has the same URL, so you can't easily go back or share a link with a friend.

133

And web search engines really hate this setup.

134

It didn't work for me either.

135

The whole point of taking space photos to the web was to make each photo easily discoverable and easily shareable.

136

That is why I implemented navigation the same way it worked 30 years ago.

137

But thanks to this support for client-side navigation in SvelKit and transitions in CSS, navigation looks much better than it looked 30 years ago.

138

Technically, you can even achieve the push and pop animations from view controllers in iOS.

139

However, after some testing, I decided to use a simple transition without the entire page sliding over another one.

140

This didn't look good on large desktop screens.

141

As I was working on this video, out of curiosity, I checked some of those Mac apps ported over from the iPad.

142

Turns out Apple has removed push and pop from most of them too.

143

Apple News is a notable exception.

144

First, it slides a new view controller over the old one.

145

And then it sends me to the browser anyway.

146

That's true genius of user-friendly UI, I'd say.

147

Again, navigation and space photos does not use some deep links resolved dynamically.

148

These are 100% real links.

149

When you click on one, it shows the content immediately with no extra loading, as if the space photo was already baked into the physical HTML document.

150

That's because it is.

151

Despite client-side navigation being available, the entire app is still pre-rendered at build time as a collection of standalone HTML documents.

152

That means users can start browsing space photos on any page.

153

And when they wanna go elsewhere, client-side navigation takes over and shows new content almost immediately and without a full reload.

154

Implementing this presented one completely unexpected problem.

155

I'll detail it in the bonus section about my deployment setup.

156

But if you don't want to subscribe to channel membership, don't worry.

157

This problem is unlikely to affect you, at least as long as your product doesn't have tens of thousands of pages.

158

Next are a couple of native features.

159

While I'll be breaking down the native shell in a future episode, there's still a lot of features that can make a web app feel more native even without a real iOS wrapper.

160

This time I'll cover those that work right in the browser, even when the app is not pinned to the home screen.

161

The most obvious one is support for the light and dark modes.

162

In CSS, enabling it takes setting a single rule.

163

It works in every browser.

164

Then you have to customize your app's color palette.

165

If you use semantic naming, just like it works in iOS, then overriding color values for the dark mode is a straightforward process.

166

The ability to store data persistently on device is what makes my app stand out, even compared to many native alternatives.

167

Back when it was a UI key app, I used Core Data for this purpose, but the web offers a robust alternative.

168

In the end, I was able to migrate from Core Data to IndexedDB with no loss of functionality and most importantly, no loss of data.

169

In a future episode, I'll explain how I moved existing records without users noticing anything.

170

To keep the length of this video reasonable, I skipped sections about accessibility and cross-browser testing.

171

I plan to cover them in separate episodes, so if you're interested, subscribe to the channel.

172

For now, let's assume that your web app works as expected on every major rendering engine.

173

So it's finally time to deploy it.

174

To keep space photos easily maintainable, I wanted to limit the number of external dependencies.

175

That is why, instead of building a live API backend, I decided to deploy the app statically.

176

As I already mentioned, SvelteKit supports pre-rendering and static site generation.

177

Building my 11,000-page app takes about 20 seconds on a laptop.

178

But obviously, production deployments use continuous integration.

179

Overall, it takes GitHub actions about 3 minutes to check out the repo, install the dependencies, build a project,

180

package it for distribution, and deploy it to Cloudflare pages.

181

Hosting a static site at the edge results in unmatched loading speed.

182

And with a couple optimization tricks explained in the following bonus section, many navigation actions don't even make extra network calls.

183

Did you notice one thing that's absent from this deployment process?

184

It's the App Store submission.

185

While Apple has greatly reduced the average review time for iOS apps in the recent years, it doesn't come close to my three-minute deployment.

186

There will be one important section right after this one, but at this point I believe I've covered all the important aspects

187

that provide a foundation for web apps that look and feel just like native apps, if not better.

188

As for the developer experience, I think you'll agree that it's much better than the Swift UIs already.

189

In the next episode, I'll cover the things that turn a regular website into a true progressive web app.

190

If you've got any questions or advice, I always welcome them in the comments.

191

Just one request, please keep your temper.

192

Claiming that WebKit on iOS is bad just because you don't like Electron apps on your PC sounds kind of ridiculous.

193

That's not what I would expect from senior engineers.

194

Speaking of electron.

195

Just before we wrap up, I will address one giant misconception I didn't pay enough attention to in my concept overview of PWA.

196

It sounds like this.

197

You're selling me an electron app.

198

I hate electron apps.

199

Everybody hates electron apps.

200

Electron apps.

201

Ah!

202

You don't like electron apps, and rightly so, but you blame the wrong part.

203

Electron's problem is not the web app inside, it's what surrounds it.

204

Every Electron app comes with a full copy of Chromium and all its dependencies, plus a large collection of native bindings to handle every use case on every platform.

205

This results in enormous bundle sizes for simple apps like chat clients.

206

Installing a new app literally adds another Chromium instance on your computer.

207

In contrast, WebKit is a system framework.

208

Instead of copying it, apps link against WebKit dynamically.

209

As for those native bindings, you only implement what you will be using.

210

There are frameworks such as Cordova and Capacitor, but I decided not to use them in space photos, precisely to keep its size under control.

211

These two differences dramatically reduce the bundle size.

212

For instance, my app is under 10 MB, most of which are actually static resources like the longscreen image.

213

At runtime, each Electron app start its own separate Chromium instance complete with all the helper processes.

214

Inside it runs your actual web app.

215

If you have two electron apps running side by side, they use roughly twice the memory.

216

This is like launching a separate web browser for every single website you visit.

217

Now see what happens when you run multiple WebKit apps.

218

Because it is a system framework, its rendering and JavaScript engines can be reused across processes, and they are.

219

The client code, including the DOM tree, the JS heap, and cookies is still sandbox to isolate apps from one another.

220

Conceptually, this is just like having a browser with one tab and then opening a second one.

221

Does this result in the doubling of the resource footprint?

222

No, it doesn't.

223

Because WebKit itself is very lean, the product's overall speed depends squarely on the web app that you write.

224

If your code is inefficient, the app will feel slow.

225

But you know who to blame in this case.

226

So the question comes down to whether you're comfortable taking responsibility for your own code.

227

I am, and that is why I'm not intimidated by WebKit, Cocoa, AutoLayout, and even Interface Builder.

228

I know that when you use them correctly, they work exactly the way you want them to and produce rock-solid, blazing-fast results, unlike SwiftUI's Blackbox.

229

So it's only a matter of engineering culture, I guess.

230

That's it for today's Codebird video.

231

If you found it illuminating, give it a thumbs up.

232

As much as I wanted to keep this episode relatively short, the director's cut still adds up to over 4000 words.

233

But I believe this is better than bringing you a high-dynamics video with terribly limited perspective.

234

You can't build good products if you operate on simple maxims like native good, web bad.

235

Sorry, but that's just immature.

236

In the next episode, we'll take another step in building web apps that feel like native apps.

237

If you're interested, subscribe to the code board and stay tuned.

238

I'll see you in the next video.

239

Until then, make your web apps fly.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

FOR YOU

המלץ על סרטון

78 משפטים

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It”. המילים שחוזרות הכי הרבה: app, web, native, photo, space. בסרטון הזה יש 239 משפטים ו-3438 מילים לתרגול Shadowing. הדיבור נמשך 19:07. הדובר מדבר מהר, כ-180 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. רק 78% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית, כך שאוצר המילים מאתגר.

אוצר מילים מרכזי בסרטון הזה

15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
electron שם עצם	/ɪˈlɛk.tɹɑn/	אֶלֶקְטְרוֹן
navigation שם עצם	/nævɪˈɡeɪʃən/	נִוּוּט, נַוָּטוּת
syntax שם עצם	/ˈsɪn.tæks/	תַּחְבִּיר
scroll שם עצם	/skɹoʊl/	מגילה, מְגִלָּה
subscribe פועל	/səbˈskɹaɪb/	נִמְנָה
megabyte שם עצם	/ˈmɛɡəˌbaɪt/	מגה־בית
accessibility שם עצם	/əkˌsɛs.əˈbɪl.ə.ti/	נְגִישׁוּת, הַנְגָּשָׁה
width שם עצם	/ˈwɪtθ/	רוחב \ רֹחַב
criterion שם עצם	/kɹaɪˈtɪɹ.i.ən/	קרִיטֶרִיוֹן
vanilla שם עצם	/vəˈnɪl.ə/	וניל
tolerate פועל	/ˈtɑ.lə.ɹeɪt/	סָבַל
dismiss פועל	/dɪsˈmɪs/	לפטר
bake פועל	/beɪk/	אָפָה
robust שם תואר	/ɹəʊˈbʌst/	חָסוֹן, אֵיתָן
canvas שם עצם	/ˈkæn.vəs/	קַנְבָס

Phrasal verbs שתשמעו

מילה	משמעות
check out פועל	בדק
figure out פועל	הֵבִין, מצא תשובה

משפטים שכדאי לחזור עליהם

משפטים קצרים ושלמים מהסרטון שאפשר להשתמש בהם בשיחה יומיומית:

In this video, I'll explain the difference.
You're right to question this.
If you don't have a membership, no worries.
It didn't work for me either.
Did you notice one thing that's absent from this deployment process?

דקדוק בסרטון הזה

המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:

מבנה	בסרטון
משפטי תנאי (Conditional sentences) if + clause, will/would + verb — תנאי ותוצאה שלו	if there's a syntax error, you'll get
סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה	is built · was preferred · is based
משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר	components, which are · rendered, which is · reactive, which is
הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו	I've been · has removed · I've covered

הגייה ששווה לשים לב אליה

הדובר משתמש ב-57 קיצורים וצורות מקוצרות, כמו I'll, don't, didn't. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

הצלילים של “th”: width /ˈwɪtθ/, threshold /ˈθɹɛʃ(h)oʊld/
הצלילים של “sh” ו-“zh”: navigation /nævɪˈɡeɪʃən/, refresh /ɹɪˈfɹɛʃ/, friction /ˈfɹɪkʃən/, specialize /ˈspɛʃəˌlaɪz/, threshold /ˈθɹɛʃ(h)oʊld/
מילים ארוכות — שימו לב להטעמה: navigation /nævɪˈɡeɪʃən/, dependency /dɪˈpɛndənsi/, importantly /ɪmˈpɔɹ.tənt.li/, reactivity /rɪˈakˈtɪvɪti/, accessibility /əkˌsɛs.əˈbɪl.ə.ti/

צלילים שדוברי עברית מתקשים בהם:

/w/ — שפתיים מעוגלות, לא /v/: width /ˈwɪtθ/, swap /ˈswɑp/, wipe /waɪp/
/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: navigation /nævɪˈɡeɪʃən/, static /ˈstæt.ɪk/, syntax /ˈsɪn.tæks/, semantic /sɪˈmæntɪk/, dynamics /dɑɪˈnæm.ɪks/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: electron /ɪˈlɛk.tɹɑn/, browser /ˈbɹaʊ.zəɹ/, render /ˈɹɛn.dɚ/, scroll /skɹoʊl/, subscribe /səbˈskɹaɪb/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו electron, navigation, syntax.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

How I deploy serverless containers for free

The UX Psychology Behind Apps People Can’t Stop Using

Is React Native Dead? Shopify Is Leaving

It’s not just you

How I Learned Procedural Generation

Video

STOP Running Code On Your Computer

Use these CSS features instead of JavaScript

How To Land Your First Junior Dev Role

Best NextJS Folder Structures | Beginner - Intermediate - Advanced

9 Insane Claude Mods I Already Can't live Without

Full day of easy home-cooked meals 🎉