Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

AndyZhang89/weak-self

Open more actions menu
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

25 Commits
 
 
 
 
 
 
 
 

Repository files navigation

weak-self

This app demonstrates when [weak self] is needed in Swift to avoid strong reference cycles, and when it is not needed.

The app accompanies an article on this topic that is available here.

Using the app

Once you clone the app from Github and open it in Xcode, navigate to PresentedController.swift to find a list of leak scenarios.

In viewDidLoad, there is a call to setup(scenario: .leakyButton). Try calling different scenarios by changing the enum case, then run the app with each scenario to observe the memory situation.

Once you run the app (on the simulator or a real device), try presenting a controller then dismissing it. You will get an alert after the dismissal telling you whether the controller has leaked (depending on the scenario you chose).

Each scenario is preceded by comments that explain what's happening and why it may or may not cause a memory leak.

The presented controller generates expensive images with Core Image filters. During leak scenarios, notice how presenting the controller multiple times in succession will keep incrementing your app memory usage.

About

This app demonstrates where [weak self] may and may not be needed

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Swift 100.0%
Morty Proxy This is a proxified and sanitized view of the page, visit original site.