DEV Community: Yi Wan

Debugging Dynamic Content Extraction: waitUntil Options in Browser Rendering Services

Yi Wan — Sat, 21 Jun 2025 09:00:12 +0000

Debugging Dynamic Content Extraction: waitUntil Options in Browser Rendering Services

When building web scraping solutions, one of the trickiest challenges is handling modern websites that load content dynamically. Today I'll share a production bug I encountered and the simple fix that solved it.

The Setup

I'm working on Zin Flow, a web-to-EPUB converter that extracts article content from web pages. Our backend uses Cloudflare's Browser Rendering service for server-side rendering and content extraction.

The Bug

Symptoms:

Local development: Full article content extracted ✅
Production: Only HTML skeleton returned ❌
Specific websites affected, others worked fine

Initial Investigation:

// Our original implementation
const page = await browser.newPage();
await page.goto(url, { 
  waitUntil: 'domcontentloaded' 
});
const content = await page.content();

This worked locally but failed in production for sites using lazy loading.

Root Cause Analysis

Modern websites, especially those built with React, Vue, or other SPA frameworks, use patterns like:

// React component with lazy loading
function ArticleContent() {
  const [content, setContent] = useState('');

  useEffect(() => {
    // Content loads after component mounts
    fetchArticleContent()
      .then(data => setContent(data));
  }, []);

  return <div>{content || 'Loading...'}</div>;
}

// Or React.lazy for code splitting
const Article = React.lazy(() => import('./Article'));

// Intersection Observer for infinite scroll
const LazyArticle = () => {
  const [isVisible, setIsVisible] = useState(false);
  const ref = useRef();

  useEffect(() => {
    const observer = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting) {
        setIsVisible(true);
        // Load content when element becomes visible
        loadDynamicContent();
      }
    });

    if (ref.current) observer.observe(ref.current);
  }, []);

  return <div ref={ref}>{isVisible ? <ActualContent /> : <Skeleton />}</div>;
};

The issue: domcontentloaded fires before these React hooks, async effects, and dynamic imports complete their execution.

waitUntil Options Explained

Browser rendering services offer several waitUntil strategies:

Option	Behavior	Use Case
`load`	Wait for `load` event	Basic static sites
`domcontentloaded`	Wait for DOM parsing	Simple dynamic sites
`networkidle0`	No network activity for 500ms	Heavy dynamic content
`networkidle2`	≤2 network connections for 500ms	Balanced approach

The Solution

// Fixed implementation
await page.goto(url, { 
  waitUntil: 'networkidle2',
  timeout: 30000  // Increased timeout for dynamic content
});

Why networkidle2 works:

Waits for most network requests to settle
Balances completeness with performance
Handles lazy loading without excessive waiting

Performance Considerations

The tradeoff matrix:

// Performance vs Completeness
const strategies = {
  'domcontentloaded': { speed: 'fast', completeness: 'low' },
  'networkidle2': { speed: 'medium', completeness: 'high' },
  'networkidle0': { speed: 'slow', completeness: 'highest' }
};

For content extraction, networkidle2 hits the sweet spot.

Advanced Patterns

For more complex scenarios, combine strategies:

// Wait for specific content indicators
await page.goto(url, { waitUntil: 'domcontentloaded' });

// Then wait for specific elements
await page.waitForSelector('.article-content', { 
  timeout: 10000 
});

// Or wait for custom conditions
await page.waitForFunction(
  () => document.querySelector('.article-content')?.children.length > 0
);

Environment Differences

Why local worked but production didn't:

Network latency: Local requests faster, content loads before extraction
Resource constraints: Production environment may load slower
Geographic differences: CDN behavior varies by location
Browser differences: Slight variations in timing

Debugging Tips

// Add logging to understand timing
console.time('page-load');
await page.goto(url, { waitUntil: 'networkidle2' });
console.timeEnd('page-load');

// Check what content is actually loaded
const contentLength = await page.evaluate(
  () => document.body.innerText.length
);
console.log(`Content length: ${contentLength}`);

Results

After the fix:

📈 Content extraction success rate: 85% → 98%
⏱️ Average processing time: +2.3s (acceptable tradeoff)
🐛 User-reported empty EPUB issues: Eliminated

Key Takeaways

Choose waitUntil strategy based on target sites - Modern sites need network-aware waiting
Test in production-like environments - Local success ≠ production success
Monitor extraction quality - Track content length and completeness metrics
Consider timeouts - Dynamic content needs longer timeouts

Tools for Testing

// Test locally with browser rendering options
// Monitor network activity in DevTools
chrome://inspect/#devices

// For Cloudflare Browser Rendering, test with:
curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/browser-render" \
  -H "Authorization: Bearer $API_TOKEN" \
  -d '{"url": "target-site.com", "waitUntil": "networkidle2"}'

For fellow developers building content extraction tools: don't underestimate the impact of waitUntil options. The right choice can mean the difference between extracting meaningful content and empty shells.

Zin Flow is available on iOS and Mac for converting web articles to EPUB format.

Discussion

What waitUntil strategies have you found most effective for your scraping projects? Any other gotchas with dynamic content extraction?

Cloudflare Worker Memory Overflow Analysis: How 20MB File Crashed 128MB Runtime

Yi Wan — Fri, 06 Jun 2025 01:36:38 +0000

TL;DR

Encountered Worker exceeded memory limit when processing 20MB files in Cloudflare Worker. Root cause: Base64 encoding + double memory allocation. Solution: Let Resend fetch files directly from R2 URLs instead of relaying through Worker.

Problem Context

Building email delivery for Zin Flow (web-to-EPUB converter) using:

Cloudflare Worker (128MB memory limit)
Cloudflare R2 (object storage)
Resend (email service)

🚨 Issue Reproduction

Error Message

Worker exceeded memory limit.

Problematic Code

// Fetch file from R2
const file = await env.R2_BUCKET.get(r2Key);

if (!file) {
  console.error(`File not found in R2: ${r2Key}`);
  return;
}

try {
  // ❌ Problem 1: First memory copy
  const fileData = await file.arrayBuffer(); // 20MB

  // ❌ Problem 2: Base64 encoding creates second copy
  const fileBase64 = arrayBufferToBase64(fileData); // ~27MB

  // Send email with attachment
  await resend.emails.send({
    attachments: [{
      filename: 'book.epub',
      content: fileBase64
    }]
  });
} catch (error) {
  console.error('Memory error:', error);
}

🔍 Deep Analysis

1. Memory Usage Breakdown

Component	Size	Notes
Original ArrayBuffer	20MB	Raw file size
Base64 String	~27MB	Base64 adds 33% overhead
V8 Engine Overhead	~30MB	Runtime base consumption
Object Metadata	~5MB	String headers, ArrayBuffer metadata
Total	~82MB	Approaching 128MB limit

2. Base64 Encoding Hidden Costs

function arrayBufferToBase64(buffer) {
  // Creates Uint8Array view (additional memory overhead)
  const bytes = new Uint8Array(buffer);

  // String concatenation creates temporary memory
  let binary = '';
  for (let i = 0; i < bytes.byteLength; i++) {
    binary += String.fromCharCode(bytes[i]);
  }

  // btoa() internal implementation needs extra memory
  return btoa(binary);
}

3. Edge Runtime Memory Characteristics

In Cloudflare's Edge Runtime, V8 memory management has specific traits:

Delayed GC: No immediate garbage collection under low pressure
String Deduplication: Large strings typically aren't deduplicated
ArrayBuffer Handling: May use off-heap memory but still counts toward limit

💡 Solution Evolution

Approach 1: Memory Optimization (Failed)

// Attempted manual memory release
const fileData = await file.arrayBuffer();
const fileBase64 = arrayBufferToBase64(fileData);

// ❌ Setting null doesn't immediately free memory
fileData = null;

// ❌ Manual GC unavailable in Workers
// global.gc?.();

Approach 2: Streaming Processing (API Limited)

// ❌ Resend doesn't support streaming uploads
const stream = file.body;
// Still need to convert to complete Base64 string

Approach 3: Architectural Redesign (✅ Final Solution)

Key insight: Resend can fetch files directly from URLs!

export default {
  async fetch(request, env) {
    const { r2Key, userEmail, fileName } = await request.json();

    // ✅ Generate public R2 URL instead of processing file
    const fileUrl = `https://${env.R2_DOMAIN}/${r2Key}`;

    // ✅ Let Resend download directly from R2
    const emailResult = await resend.emails.send({
      to: userEmail,
      subject: 'Your Zin Flow EPUB is Ready',
      html: createEmailTemplate(fileName),
      attachments: [{
        filename: fileName,
        path: fileUrl // Resend handles the download!
      }]
    });

    return new Response(JSON.stringify({
      success: true,
      messageId: emailResult.id
    }));
  }
};

function createEmailTemplate(fileName) {
  return `
    <div style="font-family: system-ui, sans-serif; max-width: 600px;">
      <h2>📚 Your EPUB is Ready!</h2>
      <p>Your ebook "${fileName}" has been converted and attached to this email.</p>

      <div style="background: #f8f9fa; padding: 20px; border-radius: 8px; margin: 20px 0;">
        <h3>📧 For Kindle Users:</h3>
        <ol>
          <li>Forward this email to your Kindle email address</li>
          <li>Or download the attachment and transfer via USB</li>
        </ol>
      </div>

      <p><small>Powered by <a href="https://zinflow.app">Zin Flow</a> - Available on 
      <a href="https://apps.apple.com/app/zin-flow/id6670145951">App Store</a></small></p>
    </div>
  `;
}

📊 Performance Comparison

Old vs New Architecture

Metric	Old Architecture	New Architecture	Improvement
Memory Peak	~82MB	~2MB	97%↓
Response Time	3-8 seconds	50-150ms	98%↓
Error Rate	15%*	<0.1%	99%↓
File Size Limit	20MB (soft)	Unlimited**	∞
User Experience	Wait + Potential Failure	Instant + Reliable	Qualitative Leap

*For large files

**Limited by email provider attachment limits

🛠️ Best Practices

1. Cloudflare Worker Memory Guidelines

// ✅ Good: Lightweight data processing
async function processMetadata(data) {
  const result = await lightweightOperation(data);
  return result;
}

// ❌ Avoid: Large file manipulation
async function processLargeFile(file) {
  const buffer = await file.arrayBuffer(); // High memory usage
  const processed = heavyProcessing(buffer); // Double allocation
  return processed;
}

2. Memory Monitoring Techniques

// Monitor memory usage in Workers
function logMemoryUsage(label) {
  const memory = performance.memory;
  if (memory) {
    console.log(`${label}:`, {
      used: `${(memory.usedJSHeapSize / 1024 / 1024).toFixed(2)}MB`,
      total: `${(memory.totalJSHeapSize / 1024 / 1024).toFixed(2)}MB`,
      limit: `${(memory.jsHeapSizeLimit / 1024 / 1024).toFixed(2)}MB`
    });
  }
}

logMemoryUsage('Before operation');
// ... perform operation
logMemoryUsage('After operation');

3. Alternative Architecture Patterns

// Pattern 1: Direct URL passing
const publicUrl = generatePublicUrl(fileKey);
await emailService.send({ attachments: [{ path: publicUrl }] });

// Pattern 2: Signed URLs with expiration
const signedUrl = await bucket.sign(key, { expiresIn: 3600 });

// Pattern 3: Redirect response
return new Response(null, {
  status: 302,
  headers: { 'Location': fileUrl }
});

// Pattern 4: Chunked processing
async function processInChunks(file, chunkSize = 1024 * 1024) {
  const stream = file.body;
  const reader = stream.getReader();

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    // Process chunk without loading entire file
    await processChunk(value);
  }
}

🎯 Key Learnings

Edge Runtime Reality: 128MB ≠ 128MB usable memory
Base64 Tax: Encoding adds 33% size + processing overhead
Architecture First: Sometimes best optimization is avoiding the problem
Service Integration: Leverage external service capabilities (Resend's URL fetching)

🚀 Real-World Impact

This solution powers Zin Flow's email delivery system, serving thousands of EPUB conversions. The app is available on App Store for iOS and Mac users who want to convert web articles into beautiful ebooks.

📚 Further Reading

🏷️ Tags

#cloudflare #workers #javascript #memory-optimization #architecture #performance #resend #email

💡 Pro Tip: When designing edge functions, always consider the hidden costs of data transformations. Sometimes the most elegant solution is letting specialized services handle what they do best.

Discussion: Have you encountered similar memory issues with Cloudflare Workers? Share your solutions in the comments! Also, check out Zin Flow if you're interested in web-to-EPUB conversion tools.

When Cloudflare D1's 2MB Limit Taught Me a Hard Lesson About Database Design

Yi Wan — Tue, 03 Jun 2025 01:15:05 +0000

As a developer working on ZinFlow, a web-to-EPUB converter app, I recently learned an expensive lesson about database constraints and proper architecture design. Let me share this painful but educational experience.

The Problem: Storing HTML Content in D1

My backend service extracts main content from web pages and processes it through what I call the "Smart Distillation Engine." Initially, I thought it would be convenient to store the extracted HTML content directly in Cloudflare's D1 database as a text field. After all, most articles aren't that large, right?

Wrong.

What I didn't pay attention to was this crucial limitation in D1's documentation:

Maximum string, BLOB or table row size: 2,000,000 bytes (2 MB)

The Disaster Strikes

Everything worked fine during development and early testing. Then users started saving longer articles, academic papers, and detailed tutorials. Suddenly, I started receiving error reports about failed saves.

The error was clear but devastating: Database row size exceeded maximum allowed size.

Users were losing their carefully curated content, and I was losing sleep trying to figure out why some articles worked while others failed spectacularly.

The Root Cause Analysis

After digging deeper, I realized several fundamental issues with my approach:

HTML content is unpredictable in size - A single long-form article can easily exceed 2MB when including embedded styles and metadata
Database bloat - Storing large text content in database rows is generally poor practice
Backup and migration nightmares - Large rows make database operations slower and more error-prone
Scalability issues - As the service grows, this design would become increasingly problematic

The Solution: Hybrid Storage Architecture

I've now refactored the backend to use a hybrid approach:

// Pseudocode for the new architecture
async function storeArticleContent(articleData) {
  const contentSize = Buffer.byteLength(articleData.html, 'utf8');

  if (contentSize > 1024 * 1024) { // 1MB threshold
    // Store large content in R2
    const r2Key = `articles/${articleData.id}/content.html`;
    await uploadToR2(r2Key, articleData.html);

    // Store metadata and reference in D1
    await d1.prepare(`
      INSERT INTO articles (id, title, url, content_location, storage_type, created_at)
      VALUES (?, ?, ?, ?, 'r2', ?)
    `).bind(
      articleData.id,
      articleData.title,
      articleData.url,
      r2Key,
      new Date().toISOString()
    ).run();
  } else {
    // Store small content directly in D1
    await d1.prepare(`
      INSERT INTO articles (id, title, url, content, storage_type, created_at)
      VALUES (?, ?, ?, ?, 'database', ?)
    `).bind(
      articleData.id,
      articleData.title,
      articleData.url,
      articleData.html,
      new Date().toISOString()
    ).run();
  }
}

Lessons Learned

Read the documentation thoroughly - Those limits exist for good reasons
Separate content from metadata - Large content should live in object storage, not relational databases
Plan for edge cases - Always consider the largest possible data your system might handle
Test with realistic data - My test articles were all small blog posts, not 50-page academic papers

The Silver Lining

This painful experience led to a much better architecture. The hybrid approach gives me:

Reliability - No more failed saves due to size limits
Performance - Faster database queries with smaller rows
Scalability - R2 can handle files of virtually any size
Cost efficiency - Object storage is cheaper for large content

For Fellow Developers

If you're building content-heavy applications with Cloudflare's stack:

Use D1 for metadata, relationships, and small structured data
Use R2 for large content, files, and binary data
Set reasonable thresholds (I chose 1MB as a safe buffer below D1's 2MB limit)
Always validate input sizes before database operations

Sometimes the most valuable lessons come from the most frustrating bugs. This experience reminded me why proper system architecture matters, especially when building services that users depend on for their important content.

Have you run into similar storage limitations? I'd love to hear about your experiences and solutions in the comments!

Building ZinFlow has been a journey of learning about web content extraction, EPUB generation, and now proper cloud architecture. If you're interested in converting web articles to e-books, you can check out the app at wanyi.dev/en/zinflow.

Debugging EPUB Language Tags: How User Feedback Led to a Deep Dive into Kindle's Font Selection Logic

Yi Wan — Fri, 30 May 2025 01:16:02 +0000

TL;DR: Red Note users couldn't access Chinese fonts on Kindle. Turns out, incorrect EPUB language metadata was the culprit. Here's how we fixed it and what I learned about e-book standards.

The Bug Report That Started Everything

Last month, I got this bug report from a Red Note user:

"My converted EPUBs look perfect in Apple Books, but on Kindle, I can't select any Chinese fonts. The text is readable but uses a Western font that looks terrible for Chinese characters."

My first thought: "That's weird, Kindle has excellent Chinese font support."

My second thought: "This is probably a quick fix."

Spoiler alert: It wasn't.

Down the Rabbit Hole

Let me show you what I discovered. When you create an EPUB file, you need to set language metadata in the content.opf file:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:language>zh-CN</dc:language>
  <!-- other metadata -->
</metadata>

Seems simple, right? But here's where it gets interesting.

The Problem

Our web scraper was detecting page language using standard HTML lang attributes:

// Simplified version of our original logic
function detectLanguage(document) {
  const htmlLang = document.documentElement.lang;
  const metaLang = document.querySelector('meta[http-equiv="content-language"]');

  return htmlLang || metaLang?.content || 'en';
}

The issue: Many websites don't properly set language attributes, or worse, have incorrect ones. Our fallback to 'en' was breaking Kindle's font selection algorithm.

How Kindle Chooses Fonts

After diving into Amazon's documentation and some reverse engineering, here's what I learned:

Kindle reads the dc:language tag from EPUB metadata
Based on this tag, it determines which font families are "appropriate"
If the language is en or unspecified, it defaults to Western fonts
Chinese fonts are only available when language is properly set to zh-CN, zh-TW, etc.

The Solution: Smarter Language Detection

Here's the improved detection logic we implemented:

function detectLanguage(document) {
  // 1. Check user preference first (stored in UserDefaults)
  const userPreference = getUserLanguagePreference();
  if (userPreference && userPreference !== 'auto') {
    return userPreference;
  }

  // 2. Check HTML lang attribute
  const htmlLang = document.documentElement.lang;
  if (htmlLang && isValidLanguageTag(htmlLang)) {
    return normalizeLanguageTag(htmlLang);
  }

  // 3. Check meta tags
  const metaLang = document.querySelector('meta[http-equiv="content-language"]')?.content;
  if (metaLang && isValidLanguageTag(metaLang)) {
    return normalizeLanguageTag(metaLang);
  }

  // 4. Check meta charset for hints
  const metaCharset = document.querySelector('meta[charset]')?.getAttribute('charset');
  if (metaCharset && metaCharset.includes('utf-8')) {
    // Additional heuristics based on page structure
    return detectFromPageStructure(document);
  }

  // 5. Fallback to English
  return 'en';
}

function getUserLanguagePreference() {
  // Swift UserDefaults integration
  return window.webkit?.messageHandlers?.preferences?.postMessage('getEPUBLanguage');
}

The key insight: user control trumps automatic detection. We added a setting in the app where users can explicitly set their preferred EPUB language, stored in UserDefaults.

Other Technical Improvements in v1.4.3

1. Native AppKit Drag-and-Drop Wrapped in SwiftUI

Users complained about our old up/down button interface for chapter sorting. The solution was native AppKit wrapped as a SwiftUI view:

struct DraggableTableView: NSViewRepresentable {
    @Binding var chapters: [Chapter]

    func makeNSView(context: Context) -> ChapterTableView {
        let tableView = ChapterTableView()
        tableView.delegate = context.coordinator
        tableView.dataSource = context.coordinator
        return tableView
    }

    func updateNSView(_ nsView: ChapterTableView, context: Context) {
        nsView.reloadData()
    }

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }

    class Coordinator: NSObject, NSTableViewDelegate, NSTableViewDataSource {
        var parent: DraggableTableView

        init(_ parent: DraggableTableView) {
            self.parent = parent
        }

        // Native AppKit drag-and-drop implementation
        func tableView(_ tableView: NSTableView, validateDrop info: NSDraggingInfo, 
                      proposedRow row: Int, 
                      proposedDropOperation dropOperation: NSTableView.DropOperation) -> NSDragOperation {
            return .move
        }

        func tableView(_ tableView: NSTableView, acceptDrop info: NSDraggingInfo, 
                      row: Int, dropOperation: NSTableView.DropOperation) -> Bool {
            // Handle the actual reordering
            return true
        }
    }
}

Result: Buttery smooth 60fps drag performance, even with large chapter lists.

2. Force Update Bug Fix

Another user pain point: stale content when articles get updated. The issue wasn't on the client side - our server wasn't properly handling force refresh requests.

The Bug: When clients sent a force update request, the server was still serving cached content.

The Fix: Properly handle the force refresh parameter on the backend:

// Server-side fix
app.get('/api/extract', async (req, res) => {
  const { url, forceRefresh } = req.query;

  if (forceRefresh === 'true') {
    // Bypass all caching layers
    await cache.delete(url);
    await redis.del(`content:${url}`);
  }

  const content = await extractContent(url, { 
    useCache: forceRefresh !== 'true' 
  });

  res.json(content);
});

Simple bug, but it was breaking the user experience when they needed fresh content.

3. Library Capacity Estimation

Users wanted to know EPUB file sizes before export. Our approach: actually build and compress the content:

async function estimateEPUBSize(articles) {
  // Create temporary EPUB structure
  const tempEPUB = new EPUBBuilder();

  for (const article of articles) {
    // Add XHTML content
    const xhtml = await convertToXHTML(article.content);
    tempEPUB.addChapter(xhtml);

    // Download and add images
    for (const imageUrl of article.images) {
      const imageData = await downloadImage(imageUrl);
      tempEPUB.addImage(imageData);
    }
  }

  // Add CSS, metadata, and structure files
  tempEPUB.addCSS(getDefaultStyles());
  tempEPUB.addMetadata(generateMetadata(articles));

  // Compress and measure
  const zipBuffer = await tempEPUB.compress();
  return zipBuffer.length;
}

Why this approach? Because EPUB compression ratios vary wildly depending on content type. Text compresses ~70%, images barely compress at all, and CSS/XML add overhead. Only way to be accurate is to actually build it.

Lessons Learned

EPUB standards matter: Small metadata issues can break entire features
Platform differences are real: What works in Apple Books might fail on Kindle
User feedback is gold: Our Chinese users caught an edge case I never would have found
Performance on Mac requires native code: SwiftUI animations weren't smooth enough for drag-and-drop

What's Next?

Working on v1.5 with focus on content quality and optimization:

Better content extraction: Improving our Smart Distillation Engine to handle more complex page layouts
EPUB file size optimization: Implementing smarter image compression and unnecessary element removal
Content cleanup: Better detection and removal of ads, navigation elements, and other noise

The goal is cleaner, smaller EPUBs without sacrificing readability.

Follow me for more adventures in cross-platform e-book generation and the surprising edge cases of web scraping.

Want to try ZinFlow v1.4.3? Download it from the App Store and check out our development blog for more technical deep dives and product updates.

Hello dev.to! My Journey from Backend to iOS/macOS Development 👋

Yi Wan — Thu, 29 May 2025 05:42:23 +0000

Introduction

Hey there! I'm excited to join the dev.to community. I'm a developer passionate about creating elegant, user-focused applications, particularly in the Apple ecosystem. You can find more about my work at wanyi.dev.

My Development Journey

My coding journey began in the backend world, working extensively with Java, Python, and JavaScript/TypeScript. I spent years building robust server-side applications, APIs, and full-stack solutions. But something was always calling me toward creating more direct, tangible user experiences.

That's when I discovered Swift and SwiftUI. The elegance of Swift's syntax, combined with SwiftUI's declarative approach to UI development, completely changed my perspective on app development. I fell in love with Apple's Human Interface Guidelines and the philosophy of creating intuitive, beautiful user experiences.

The Birth of ZinFlow

The Problem That Started It All

Like many developers, I'm an avid reader. I often found myself wanting to save long articles from the web to read later on my Kindle. The existing solutions were either clunky, didn't format content well, or required complex workflows. I thought, "There has to be a better way."

Building the Solution

That's how ZinFlow was born - a macOS and iOS app that transforms web content into beautifully formatted EPUB e-books.

The Technical Challenge

The core challenge wasn't just extracting content from web pages (though that's complex enough!). It was about:

Intelligent Content Extraction: Building a Smart Distillation Engine that could identify the main content while filtering out ads, navigation, and other noise
Cross-Platform Architecture: Ensuring seamless experience across macOS and iOS using SwiftUI
Data Synchronization: Implementing iCloud sync so users could save articles on one device and access them on another
Format Conversion: Converting extracted content into clean, readable EPUB files

The Evolution

ZinFlow started as a simple URL-to-EPUB converter, but user feedback drove exciting new features:

v1.3 Breakthrough: The Library Feature

Users wanted a "read it later" experience
Added a personal library where users can collect articles
Implemented batch export - select multiple articles and create a single EPUB with custom chapter ordering
Built an in-app browser for accessing content behind paywalls

Technical Stack Highlights

SwiftUI for cross-platform UI
SwiftData for local data management and iCloud sync
Swift 6 concurrency for smooth background processing
Share Extensions (iOS) for seamless integration with other apps
Backend Processing for intelligent content extraction

What I'm Learning Now

Currently exploring:

Advanced SwiftUI animations and SF Symbols 6 integration
Swift 6 concurrency patterns for better user experiences
App Store optimization and ASO strategies
Building sustainable indie app businesses

The Philosophy Behind My Work

What drives me is the intersection of technology and accessibility. There's something deeply satisfying about taking messy, cluttered web content and transforming it into clean, readable material. It's not just about the code - it's about respecting the reader's time and attention.

I believe great apps should feel invisible - they solve problems so elegantly that users don't think about the complexity underneath.

What's Next

I'm always working on making ZinFlow better, but the journey is far from over. My biggest focus right now is continuously refining the Smart Distillation Engine.

Content extraction from the wild web is fascinatingly complex - every website has its own structure, some use dynamic loading, others hide content behind overlays or within complex DOM hierarchies. It's an ongoing algorithmic challenge that keeps me engaged. I'm constantly analyzing extraction failures, studying new website patterns, and fine-tuning the engine to handle edge cases better.

This isn't a "set it and forget it" kind of problem - it's a living system that needs to evolve with the ever-changing web landscape. Each improvement makes the reading experience smoother for users, and there's something deeply satisfying about turning a cluttered, ad-heavy webpage into clean, focused content.

Beyond ZinFlow, I'm exploring new ideas in the productivity and content space. The Apple ecosystem offers incredible opportunities for developers who care about craftsmanship and user experience.

Let's Connect!

I'm excited to be part of this community and looking forward to:

Sharing insights about SwiftUI development
Discussing App Store strategies and indie app development
Learning from your experiences and perspectives
Collaborating on interesting projects

Especially keen to connect with fellow reading enthusiasts! If you're a Kindle lover, iPad reader, or just someone who's passionate about digital reading experiences, I'd love to hear from you. What's your ideal reading setup? How do you manage your digital library? What frustrations do you have with current reading tools?

These conversations often spark the best feature ideas and help me understand what readers actually need versus what I think they need.

Feel free to reach out if you want to chat about Swift development, app design decisions, reading workflows, or just share what you're building. You can find me here on dev.to or check out my work at wanyi.dev.

What brought you to iOS/macOS development? And what's your favorite way to read digital content? I'd love to hear your story!